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 18:04:45 GMT
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, xcalia
>>
>> 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
>> 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!


Mime
View raw message