Hello all,

I'm trying to update an object "a" of type "A" in a database (PostgresSQL) via the EntityManager.merge() method but it seems like the data are not edited in the base soon enough.
Let's say "a" has a field name set to null and I wanna edit it.

The scenario is as follows :
1 a user requests an EJB service to edit the name of "a" (client side);
2 the EJB service resquests the DAO to edit the database (server side);
3 the DAO returns the "a" object with its name edited but when I look in the database nothing changed (server side);
4 the EJB service returns the object "a" edited by the DAO up to the client;
5 the client requests the EJB service to find all the objects of type A.

The problem here is at step 5 the database still hasn't been modified and "a" has not its name edited. But if I delay step 5 of a serveral hundred millisecs the name is edited just as expected.

Obviously the EntityManager.merge() method doesn't edit the database right away. I've tried the EntityManager.flush() method but nothing changed. Does anyone have any good tip to provide ?

Thx

Bibi

It sounds like you have a race condition related to transaction issues. Your second request for the same, but edited object is coming through and being satisfied before the transaction of your first request commits. Essentially your transaction should be complete and your work committed before step #4 completes.

Without having explicitly-defined transaction start/end, you might be at the whim of the connection pool release/auto-commit or JVM garbage collection as to the precise moment when your transaction commits. I can't really comment further without knowing how you're managing transactions or whether or not you're using JTA. Personally I use Spring with a local (non-jta) transaction manager, and do transaction demarcation in my service layer (per-method) so it's clear which methods are write, which methods are read-only, and when my work will be committed to the database.

Thanks for your answer it really helped.

I solved my problem by adding "@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)" to the DAO method implementation.

Bibi

right, people please remember: any change you make to the database is applied only at transaction commit, not at the line you invoke a JPA method.

thank you silvaran for all help you're providing!

You're welcome :).

I've had problems with requires_new before. Specifically with nested transactions and the readOnly flag (which only Hibernate makes use of I believe). So my general pattern is:

- No demarcation on my DAOs. Put it all on the services that use the DAOs. This way when you make 2 DAO calls within one service call, and the second one fails, you can still roll back the first one.
- Mark all of my service classes with rollback=Throwable, and SUPPORTS for the propagation method.
- Mark any methods that need write support so I can turn off the readonly flag (I'm not familiar with TransactionAttribute, but my annotations are Spring-specific).

requires_new is good if you have a transaction you want to commit (like some kind of logging/audit function) even if the rest of your data manipulation needs to be rolled back.