Re: How does an explicit EntityManager.lock() call prevent dirtyreadsin JPA

[Miłosz Tylenda <mt...@o2.pl>]

Vlad,

I agree with your thinking on your scenario. That's why I think you need row locking in the database and it matters when you call lock() in order to prevent T2's dirty read.

Greetings,
Milosz


> Hello Milozs,
> 
> thanks for your reply. Maybe you are right, anyway, pls comment on my
> scenario. There is nothing preventing T2 from commiting with a dirty read;
> the lock() call doesen't even get the chance to be called.
> 
> Waiting for your opinion.
> 
> 
> Miłosz Tylenda wrote:
> > 
> > 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.
> >> 
> >> 
> > 
> > 
> 
> -- 
> View this message in context: http://n2.nabble.com/How-does-an-explicit-EntityManager.lock%28%29-call-prevent-dirty-reads-in-JPA-tp1480410p1486495.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
> 
>