openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vladbalan <>
Subject How does an explicit EntityManager.lock() call prevent dirty reads in JPA
Date Mon, 10 Nov 2008 13:26:16 GMT


i'm trying to understand the behaviour of the EntityManager.lock() call. 
The Sun documentation ( 
on this is a bit confusing for me and i will explain why. It says that if T1
calls EntityManager.lock() on an entity, then T2 couldn't make a dirty read. 
Also i read here ( that " 
The lock() API acquires an optimistic lock, not a pessimistic lock. It means
that the version will be checked, or updated on commit, it does not matter
when it is called in the transaction, as the check occurs on commit 
So it does not matter when the lock call is made. Ok, now let's imagine the
following typical scenario of the dirty read in a time-point follow-up: 
T1                                           T2 
T1: W(edit some entity E) 
                                              T2: R(reads E) 
                                              T2: commit 
T1: lock(E) 
T1: commit 
So there is nothing from preventing T2 to commit in this concurrent
transaction scenario and thus making a dirty read. 
So my guess is: 
- either the javadoc would be wrong presenting that T1 is the one doing the
lock() call instead of T2 doing it. 
- or the lock() call moment is infact important and, in this case, doing it
before the W(edit) in T1 should solve the problem. 
Would be nice to give the insights on how this works. Thanks. 

View this message in context:
Sent from the OpenJPA Developers mailing list archive at

View raw message