db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Optimistic locking - not 100% reliable without triggers?
Date Tue, 14 Mar 2006 11:19:59 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message