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 Sat, 07 Feb 2009 14:10:52 GMT
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?



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 to
>>>> [1].
>>>>    By the way, the test case is very neat!
>>>> [1]

View raw message