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 <[EMAIL PROTECTED]>: > 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 >
