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 17:53:59 GMT
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.
> 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!


Mime
View raw message