db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Bengtson <e...@jpox.org>
Subject Re: Optimistic locking - not 100% reliable without triggers?
Date Tue, 14 Mar 2006 11:58:34 GMT
Jorg,

You already has the solution: increase the isolation level. JPOX will try to
hold the database transaction the less time as possible.

Regards,

Quoting Jörg von Frantzius <joerg.von.frantzius@artnology.com>:

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




Mime
View raw message