openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <ppod...@apache.org>
Subject Re: Is the implementation of lock(LockModeType.READ) correct?
Date Mon, 16 Feb 2009 14:10:49 GMT

Hi Philip,
The flag exists and its documentation/naming indicates that it should do
what you are asking for. And you are right that it is set to true for
VersionLockManager -- which is the default for optimistic transactions. But
I see no other part of the code is making use of this flag. More
investigation is required. But as I am busy with some performance
enhancement drug (oops, work;) for OpenJPA I am not being able to pay enough
attention to this thread.
 

Philip Aston wrote:
> 
> 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--tp2272546p2334993.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.


Mime
View raw message