Hi Gordon,
i wanted to have your opinion on 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 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 i 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 [u]is[/u] infact important and, in this case, doing it before the W(edit) in T1 should solve the problem.
Would be nice to give some hints on how this works.
Thanks.
Vlad
[Message sent by forum member 'vladbalan' (vladbalan)]
http://forums.java.net/jive/thread.jspa?messageID=315726