openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vladbalan <vlad.ba...@gmail.com>
Subject Re: How does an explicit EntityManager.lock() call prevent dirty readsin JPA
Date Tue, 11 Nov 2008 19:19:43 GMT

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.


Mime
View raw message