Using serializable transactions is one option. The main issue with serializable transactions is they are database dependent and everything read in the transaction will be locked, and can cause deadlocks in certain cases. But depending on your database this may be the best solution.
Another option is using pessimistic locking through "Select ... for Update", this is supported through the "eclipseLink.pessimistic-lock" query hint. This gives you more control over what is locked, but is still database dependent, and not part of the JPA spec yet.
You can also use optimistic locking read-locking. JPA has a lock() API on EntityManager that allows the object's version locked to be check even if just read. This may be the best solution, as it is supported by the JPA spec, and less database dependent and less prone to deadlocks.
Also see:
http://en.wikibooks.org/wiki/Java_Persistence/Locking#Pessimistic_Lockingfor more info on locking.
I'm using
OC4J as my server
Eclipselink as my jpa provider
Spring to inject the container managed entity manager and the JTA transactions.
I think that using the serializable isolation level on the transaction would achieve our requirements.
Richard
ageing student wrote:
Hi,
I have a requirement to read several unrelated entities. The relative state of the loaded entities should be as at a specific point in time i.e. the start of the read operation. Meanwhile other servers may be writing to the database and I don't wish to include any writes that occur after the read transaction has started.
So if I want to load entities A and B, but whilst I'm loading entity A someone else writes an update to entity B, when I move on to load entity B I wish to load the data prior to the update.
I think that using isolation levels is the way to go but am unclear on their use.
