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. > >
