How to setAutoCommit to false in JPA2 transactions?

Question

I am very sorry for the multiple posting I issued, I apologized and but it didn't work apparently.
In the rolling back from a partially failed transaction acting on several entities, gimbal2 suggested turning the autoCommit off (maybe something like setAutoCommit(false)). Any idea how one does this in JPA 2 + Eclipselink + Glassfish 3.1?
Many thanks.

Answer 1

Your DAO layer should not really get so complicated that you can't post a SSCE that demonstrates the problem, especially if you are using JPA. You are probably already manually doing too much that should be left to JPA with the right relationships and cascade types set. I really think you should use this as a warning that there is something wrong and consider simplying things before your DAO gets too complicated for any changes to be made to it. An exception always causes the current transaction to be marked for rollback as long as it's not an application exception. Either
1.) You are using open session in view
2.) You are calling other methods that are running in their own transaction different from the calling transaction.
3.) You are manually forcing commits at some points in your code.
It is extremely unlikely that there is a bug in your container's JTA implementation that is causing this.Many thanks for your time.
To your points above.
1) Sorry, would you be more specific to what you mean?
2) I was, but then I eliminated all long-distance calls and made them all local! You will see below.
3) Yes I do, but no flushing; otherwise how would I persist?
Very well then, here is an pseude-SSCE that causes the failures I am talking about, do excuse me for being verbose (academia-inherited).
I have the following entities for a conference management system we are building. I have:
- Participant, any new user will become a participant in the system
- Referee, the new user could then assume the roles of a referee, author, attendee... or a combo
// supper class for sharing code
@MappedSuperclass
public abstract class ParentEntity implements Serializable {
   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   private Integer id;
   // other objects, setters, getters...
// a participant in the system could assume several roles, a key-per-role however
@Entity
public class ZparticipantRole implements Serializable {
   @Id
   private Integer id;
@Entity
public class Participant extends ParentEntity {
   @OneToMany
   private List<ZparticipantRole> zparticipantRoles = new ArrayList<ZparticipantRole>();
   // other objects, setters, getters...
@Entity
public class Referee extends ParentEntity {
   @OneToOne
   private Participant participant = new Participant();  
   // other objects, setters, getters...
Here is how persistence.xml looks, running on GF 3.1, NB 7, JPA 2, Eclipselink impl.
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
    http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
  <persistence-unit name="default" transaction-type="JTA">
    <jta-data-source>mysql_mecms</jta-data-source>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <validation-mode>NONE</validation-mode>
    <properties>
    </properties>
  </persistence-unit>
</persistence>
// managed bean that fetches data from the frontend to dispatch for transaction management
@ManagedBean
@ViewScoped
public class EventRegRefereeController implements Serializable {
   @EJB
   private JPAManager jpaManager;
   // other data, setters and getters
   // method called from JSF page
   public void regAsRef() {
      boolean statusOk = true;
      try {
         // participant is already persisted, but referee is new
         jpaManager.createReferee(referee, participant);
      } catch (Exception e) {
         statusOk = false;
      // life goes on...
@Stateless
public class JPAManager implements Serializable {
   @PersistenceContext(unitName = "default")
   private EntityManager em;
   final int AUTHOR_ROLE = 1;
   final int REFEREE_ROLE = 2;
   public void createReferee(Referee referee, Participant participant) {
      referee.setParticipant(participant);
      em.persist(referee);
      ZparticipantRole refereeRole = em.getReference(ZparticipantRole.class, REFEREE_ROLE);
      participant.getZparticipantRoles().add(refereeRole);
      em.merge(participant);
   // other methods...
}So all the necessary ingredients are above. Here is what happens, and I will use code-style to preserve indentation.
  1. Database empty, a new user comes so they would be registered as a participant, call them p1 with id=1
  2. p1 comes back to register as referee,
    2.1 participant is fetched using "em.find()",
    2.2 new referee is created
    2.3 jpaManager is called on them (jpaManager.createReferee(referee, participant);)
   Since referee is brand new, all goes ok, call them r1 with id=1
  3. There is a table called participant_zparticipantrole and it has the following entry: (Participant_ID, zparticipantRoles_ID) = (1, 2)
  4. Suppose now that we execute a bad piece of code... what's better than Step 2.3 above? That is, the SAME referee on the SAME participant (just bear with me... I know that's bad and avoidable), here is what happens:
    4.1 The same referee arrives to the createReferee method, but, because the key-generation is IDENTITY, the old (id=1) is neglected and a new id=2 for the referee is created and persisted. So far, we deserve it
    4.2 The this piece is executed: participant.getZparticipantRoles().add(refereeRole)... see it? This is bad, we are putting the same record ((Participant_ID, zparticipantRoles_ID) = (1, 2)) in the same table! And it fails, rightly so.
    4.3 An exception is thrown, something like this:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '1-2' for key 1
Error Code: 1062
Call: INSERT INTO PARTICIPANT_ZPARTICIPANTROLE (zparticipantRoles_ID, Participant_ID) VALUES (?, ?)
and this statement appears in the exception:
Caused by: javax.transaction.RollbackException: Transaction marked for rollback.
...Yet, the new record inserted for the referee is never rolled back! My referee table has two entries with id=1 and id=2. This is where I was expecting a rollback. That got us worried, suppose there is a piece of a faulty logic lurking somewhere that would give way sometime due to some failure, our database is... smudged!
So?