openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MiƂosz Tylenda <mtyle...@o2.pl>
Subject Re: How does an explicit EntityManager.lock() call prevent dirty readsin JPA
Date Tue, 11 Nov 2008 17:38:56 GMT
Vlad,

Maybe the cited sentence is not correct? It says:

> 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 

But if you read the JPA spec it says exactly what you have read in the JavaDoc but also adds:

"This will generally be achieved by the entity manager acquiring a lock on the underlying
database row.
Any such lock may be obtained immediately (so long as it is retained until commit completes),
or the
lock may be deferred until commit time (although even then it must be retained until the commit
com-
pletes). Any implementation that supports repeatable reads in a way that prevents the above
phenomena
is permissible."

I understand from this that an implementation can do a SELECT FOR UPDATE for a lock() instead
of being restricted to optimistic concurrency control.

Greetings,
Milosz



> 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