openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Ezzio <>
Subject Re: Is the implementation of lock(LockModeType.READ) correct?
Date Sun, 08 Feb 2009 13:32:43 GMT
Hi Philip,

When two transactions read the same version of AccountSummary, both 
cannot successfully update its sum.  Only one will successfully commit.


Philip Aston wrote:
> Suppose Innocent read locks a bunch of Accounts, sums up the value, and
> writing out the total to a separate AccountSummary entity. Innocent
> begins its commit, and its read locks are validated.
> Meanwhile InnocentToo modifies an Account, taking care to update the
> total in AccountSummary.
> Innocent finishes its commit.
> The total in account summary is now wrong.
> Due to this "corner case", the OpenJPA read lock implementation can't be
> relied on.
> - Phil
> dezzio (via Nabble) wrote:
>> Hi Philip and Pinaki,
>> Since Philip brought his test case to me before coming here, I am
>> familiar with it. So, I'll try to elucidate.
>> The test case concerns the order of operations within the OpenJPA commit
>> method as seen over the two JDBC connections involved. (Philip actually
>> uses three transactions, but the third is just to make the timings of
>> the other two always come out the same.)
>> Time sequence:
>>      Innocent: SELECT to check version of Flag1 (passes)
>>      Evil:     UPDATE to change Flag1 (does not block)
>>      Evil:     COMMIT (succeeds)
>>      Innocent: UPDATE to change Flag2 (does not block)
>>      Innocent: COMMIT (succeeds)
>> Philip's argument is that both transactions ought not to succeed since
>> Innocent holds a READ lock on Flag1 that ought to be enforced until his
>> transaction commits.
>> I believe that the implementor's argument is that optimistic
>> transactions ought to avoid deadlock, and READ locks ought not to
>> increase the chances of deadlock.
>> To accomplish this end, it is acceptable to allow evil to triumph,in
>> this test case, especially since Evil has not caused any harm.
>> Presumably, whatever information in the object Flag1 that Innocent
>> relied upon has already been used to modify the object Flag2, and the
>> net result is that image in the database is the same as it would be if
>> Evil has dallied until Innocent was done. On the other hand, if Evil had
>> been eager to accomplish his nefarious deed, Innocent's transaction
>> would not have succeeded.
>> In short, Philip, where is the harm?
>> Cheers,
>> David
>> Philip Aston wrote:
>>> All understood and agreed.
>>> The problem is not 1., and I'm using read committed. The problem is in
>> the
>>> implementation of the VersionLockManager itself. It does the check, then
>>> leaves a gap where the data can be modified by a separate commit
>> before the
>>> update happens.  Thus its actual behaviour is "verifying that the
>> version of
>>> all read-locked instances is unchanged at the start of the commit of the
>>> transaction".
>>> Pinaki Poddar wrote:
>>>> Hi Philip,
>>>>   I did not execute the test case but reading it gave me the impression
>>>> that it is exercising/exposing the following known limitation. But
>> may be
>>>> I should analyze the test case deeper to understand what is causing this
>>>> behavior.
>>>> 1. "In order to maintain reasonable performance levels when loading
>> object
>>>> state, OpenJPA can only guarantee that an object is locked at the proper
>>>> lock level after the state has been retrieved from the database. This
>>>> means that it is technically possible for another transaction to "sneak
>>>> in" and modify the database record after OpenJPA retrieves the state,
>> but
>>>> before it locks the object. The only way to positively guarantee that
>> the
>>>> object is locked and has the most recent state to refresh the object
>> after
>>>> locking it."
>>>>   2. On VersionLockManager (which is the default and being used in this
>>>> case): "This lock manager does not perform any exclusive locking, but
>>>> instead ensures read consistency by verifying that the version of all
>>>> read-locked instances is unchanged at the end of the transaction."
>>>>   3. Another possibly relevant point: "In order for the version lock
>>>> manager to prevent the dirty read phenomenon, the underlying data
>> store's
>>>> transaction isolation level must be set to the equivalent of "read
>>>> committed" or higher."
>>>> Philip Aston wrote:
>>>>> Thanks Pinaki.
>>>>> I don't think the documented known issues cover my case. The first
>> bullet
>>>>> point is about the pessimistic lock manager, which I'm not using. The
>>>>> second bullet is about the read consistency of the locked object - this
>>>>> isn't the problem either. The last paragraph is again about the
>>>>> pessimistic lock manager. And I don't see any of the INFO level
>> messages
>>>>> referred to.
>>>>> I find the documented issues to be reasonable, but I'm afraid I
>> can't say
>>>>> the same of the read locking implementation.
>>>>> - Phil
>>>>> Pinaki Poddar wrote:
>>>>>> Hi Philip,
>>>>>>    The points you raise are valid, correct and known. Please refer
>>>>>> [1].
>>>>>>    By the way, the test case is very neat!
>>>>>> [1]

View raw message