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.
