EntityManager unwanted background commit

Question

I have a strange problem on one of my glassfish server. Have a look on this piece of code:

userTransaction.begin();

MyEntity entity = new MyEntity(12345);
//setting values..
entityManager.persist(entity);

MyEntity persistedEntity = entityManager.createQuery("SELECT p FROM MyEntity p WHERE p.idpk=12345").getSingleResult();
//...

userTransaction.commit(); //OK => the tuple is in the DB

Now there is a business problem and the transaction needs to be rollbacked.

userTransaction.begin();

MyEntity entity = new MyEntity(12345);
//setting values..
entityManager.persist(entity);

MyEntity persistedEntity = entityManager.createQuery("SELECT p FROM MyEntity p WHERE p.idpk=12345").getSingleResult();
//...

//Business problem => rollback
userTransaction.rollback(); //ERROR => the tuple 12345 is in the DB !

Even if the rollback seems to work (no exception raised or strange log output), the tuple has been committed in the database... To search where the problem is, I tried the following code:

userTransaction.begin();

MyEntity entity = new MyEntity(12345);
//setting values..
entityManager.persist(entity);

//Business problem => rollback
userTransaction.rollback(); //OK => the tuple 12345 is NOT in the DB !

With this code (the entity is not retrieved), the tuple is not committed to the database, which is the correct behaviour. Let's go further:

userTransaction.begin();

MyEntity entity = new MyEntity(12345);
//setting values..
entityManager.persist(entity);

MyEntity persisted = entityManager.find(MyEntity.class, 12345);
//...

//Business problem => rollback
userTransaction.rollback(); //OK => the tuple 12345 is NOT in DB

In this last case, the result is still correct and there is no tuple committed to the database. It seems the EntityManager makes a magic [unwanted] commit when retrieving the entity with a query... I also tried to make a query on another table and that doesn't cause the wrong commit (the rollback works). Moreover, I tried to reproduce the problem on my own server, and there is no problem: all the rollbacks work correctly. Hence, it should really be a server configuration problem.

For information, it is a glassfish v2.1.1 running on linux. The EntityManager is in FlushModeType.AUTO.

Does anyone have an idea ?

Thanks & best regards !

Answer 1

Found some discussion which seems to explain some of what you're seeing:

Via P-331 of EJB3 In Action Book:

By default, the database flush mode is set to AUTO. This means that the Entity-Manager performs a flush operation automatically as needed. In general, this occurs at the end of a transaction for transaction-scoped EntityManagers and when the persistence context is closed for application-managed or extendedscope EntityManagers. In addition, if entities with pending changes are used in a query, the persistence provider will flush changes to the database before executing the query. If the flush mode is set to COMMIT, the persistence provider will only synchronize with the database when the transaction commits. However, you should be careful with this, as it will be your responsibility to synchronize entity state with the database before executing a query. If you don’t do this and an EntityManager query returns stale entities from the database, the application can wind up in an inconsistent state.

P-353 EJB3 In Action Book states:

If the Query is set to FlushModeType.COMMIT, the effect of updates made to entities in the persistence context is not defined by the specification, and the actual behavior is implementation specific.

Perhaps try toggling the flush mode on the query returned by

entityManager.createQuery("SELECT p FROM MyEntity p WHERE p.idpk=12345").getSingleResult();

or on the entity manager itself and see if that changes anything?

Some further discussion here:

http://www.coderanch.com/t/475041/ORM/databases/EntityManager-setFlushMode-COMMIT-Vs-Query