db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Optimistic locking - not 100% reliable without triggers?
Date Tue, 14 Mar 2006 19:50:22 GMT
Hi Jörg,

On Mar 14, 2006, at 11:34 AM, Jörg von Frantzius wrote:

> 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?

No, commit() will do it. But a flush() is required to report version  
exceptions.

Craig

>>
>> 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!
>>
>>
>

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
View raw message