db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: Optimistic locking - not 100% reliable without triggers?
Date Tue, 14 Mar 2006 19:34:05 GMT
Craig L Russell schrieb:
> Hi Jörg,
>
> On Mar 14, 2006, at 10:42 AM, Jörg von Frantzius wrote:
>
>> Hello Craig,
>>
>> do you or does anybody else see a problem in deferring verification 
>> and update of versions to the end of the transaction?
>
> In my experience, deferring verification and update of versions to the 
> end of the transaction is best practice. Of course, if you use the 
> flush method the implementation has no choice.
Is flush() required to update version columns?
>
> Craig
>
>> Compared to JPOX' current implementation, in my opinion this would 
>> decrease database deadlock probability a lot. At the moment, locking 
>> would be dispersed over time of the transaction, as verification 
>> happens with every update request issued. For implications on the 
>> number of statements, please see the said JPOX issue 
>> <http://www.jpox.org/servlet/jira/browse/CORE-2743>.
>>
>> Regards,
>> Jörg
>>
>> Craig L Russell schrieb:
>>> Oops,
>>>
>>> On Mar 14, 2006, at 9:53 AM, Craig L Russell wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> On Mar 14, 2006, at 4:01 AM, Eric Samson wrote:
>>>>
>>>>> Hello Jörg
>>>>>
>>>>>  
>>>>>
>>>>> One common portable solution to this is to acquire locks during 
>>>>> the conflict detection step (using SELECT for UPDATE instead of 
>>>>> simple SELECT).
>>>>>
>>>> This would typically involve a user configuration setting, either 
>>>> globally or on a per-class basis. It's been implemented in e.g. the 
>>>> SunOne application server CMP as policy "lock-when-loaded" on a 
>>>> persistent class.
>>>
>>> This is noise. Doesn't apply to optimistic scenarios. Eric's 
>>> comments are spot on.
>>>
>>> Craig
>>>>>
>>>>> Another approach could be to perform the conflict detection and 
>>>>> the update at the same time (statement like “UPDATE WHERE pk=OID 
>>>>> AND TS=ts”), but it raises some concerns for the conflict 
>>>>> resolution (most JDBC drivers are not able to indicate which rows 
>>>>> raised an exception).
>>>>>
>>>> I don't follow this. The UPDATE statement only updates one row at a 
>>>> time so I don't know why this would be an issue. This is the 
>>>> recommended solution from me.
>>>>
>>>> Craig
>>>>>
>>>>>  
>>>>>
>>>>> Best Regards
>>>>>
>>>>> **...****.:**** Eric Samson, Founder & CTO, x****calia******
>>>>>
>>>>> //Service your Data!//
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> *De :* Jörg von Frantzius [mailto:joerg.von.frantzius@artnology.com]
>>>>> *Envoyé :* mardi 14 mars 2006 12:20
>>>>> *À :* jdo-dev@db.apache.org <mailto:jdo-dev@db.apache.org>
>>>>> *Cc :* JDO Expert Group
>>>>> *Objet :* Optimistic locking - not 100% reliable without triggers?
>>>>>
>>>>>  
>>>>>
>>>>> Hi,
>>>>>
>>>>> JPOX optimistic version verification entirely takes place within 
>>>>> the VM, by reading a version column and comparing it with an 
>>>>> expected value. When it verfies OK, JPOX proceeds and updates the 
>>>>> version column with a new value. That means verification and 
>>>>> update of version do not happen atomically, at least not on the 
>>>>> database level, unless at least REPEATABLE_READ is used.
>>>>>
>>>>> Now if two threads or processes want to update the same row, and 
>>>>> happen to verify the row's version at the same time, it is 
>>>>> theoretically possible that they both decide to update it, i.e. 
>>>>> none of them will receive a JDOOptimisticVerificationException. 
>>>>> Using READ_UNCOMMITTED instead of READ_COMMITTED for verifying the 
>>>>> version column will increase chances of detecting a conflict, but 
>>>>> still a conflict can remain undetected.
>>>>>
>>>>> In Oracle's suggestion for implementing optimistic locking, the 
>>>>> process will write the same optimistic version that it had 
>>>>> previously read, and a trigger on the database will do the 
>>>>> verification and increment the version if it had not been so yet. 
>>>>> I guess that the trigger executes atomically, so conflicts will 
>>>>> always be detected.
>>>>>
>>>>> Am I wrong here somewhere or do we really need triggers to have 
>>>>> 100% reliability of conflict detection?
>>>>>
>>>>> Thanks for any hints,
>>>>> Jörg
>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message