openjpa-dev mailing list archives

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

Hi, 

i'm trying to understand the behaviour of the EntityManager.lock() call. 
The Sun documentation (
http://java.sun.com/javaee/5/docs/api/javax/persistence/LockModeType.html) 
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 (http://www.nabble.com/JPA-locking-td19525631.html) 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. 

Vlad 
-- 
View this message in context: http://n2.nabble.com/How-does-an-explicit-EntityManager.lock%28%29-call-prevent-dirty-reads-in-JPA-tp1480410p1480410.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.


Mime
View raw message