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.
