openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Aston <phil...@mail.com>
Subject Re: Is the implementation of lock(LockModeType.READ) correct?
Date Mon, 16 Feb 2009 08:03:03 GMT

Thanks Pinaki,

Are you sure? Setting:

      <property name="openjpa.LockManager"
value="version(VersionCheckOnReadLock=true)"/>

doesn't change the behavior of my case, and AFAICS from the code "true" is
the default for VersionCheckOnReadLock with the version lock manager.

- Phil


Pinaki Poddar wrote:
> 
> Philip,
>>  do the optimistic lock checks for read locks after the INSERT, DELETE,
>> and UPDATES for the transaction.
>   This is currently possible with setting VersionCheckOnReadLock property
> on LockManager.
> I think this will ensure that all three Flags become part of commit set
> and thus the transactional consistent extends to consistency of the entire
> dataset that the test case is demanding.
> 
> Pinaki
>  
> 
> Philip Aston wrote:
>> 
>> Hi David,
>> 
>> EL does an update for each read lock at commit time, setting its version
>> column to the same value. See my other post - I agree that SELECT FOR
>> UPDATE is not appropriate for read locks, and I instead suggest a third
>> approach; that is to do the optimistic lock checks for read locks after
>> the INSERT, DELETE, and UPDATES for the transaction.
>> 
>> - Phil
>> 
>> 
>> 
>> dezzio wrote:
>>> 
>>> Hi Philip,
>>> 
>>> But why does EclipseLink pass the test?
>>> 
>>> Clearly the implementation could use SELECT FOR UPDATE when it checks 
>>> the READ lock's state prior to commit.  If it did that, then both 
>>> transactions would not succeed, and in fact, due to the likelihood of 
>>> deadlock in our example case, they both might fail.
>>> 
>>> These kind of issues do not get sorted by argument.  They are settled by 
>>> test cases in the TCK.  For this issue, there is no TCK test case, and 
>>> thus, ipso facto, OpenJPA complies with the spec.  You can still argue 
>>> that it doesn't comply with the spec in the best way, and you may be 
>>> right.  I could be persuaded by understanding the behavior of competing 
>>> implementations.
>>> 
>>> Cheers,
>>> 
>>> David
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/Is-the-implementation-of-lock%28LockModeType.READ%29-correct--tp2272546p2333637.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.


Mime
View raw message