Craig L Russell schrieb:
Hi Jörg,
On Mar 14, 2006, at 11:34 AM, Jörg von Frantzius wrote:
Craig L Russell schrieb:
Hi Jörg,
On Mar 14, 2006, at 10:42 AM, Jörg von Frantzius wrote:
Hello Craig,
do you or does anybody else see a problem in deferring verification
and update of versions to the end of the transaction?
In my experience, deferring verification and update of versions to
the end of the transaction is best practice. Of course, if you use
the flush method the implementation has no choice.
Is flush() required to update version columns?
I'm afraid this question is ambiguous. I'll answer both possible
interpretations of the question.
1. Is the user required to call flush in order to update version
columns? No. Commit will also update version columns.
2. If the user calls flush(), is the implementation required to update
version columns? Yes. Flush forces changes to the datastore, and
reports exceptions, including version mismatches.
As version data is not directly accessible by any user queries, would it
have any consequences to exempt optimistic version information from the
requirement "forces changes to the datastore"? Can you think of any
use-case where application code (or external systems) rely on version
information being stored during flush()?
For the verification itself I think it is not necessary to update
version information during flush().
Craig
Craig
Compared to JPOX' current implementation, in my opinion this would
decrease database deadlock probability a lot. At the moment,
locking would be dispersed over time of the transaction, as
verification happens with every update request issued. For
implications on the number of statements, please see the said JPOX
issue <http://www.jpox.org/servlet/jira/browse/CORE-2743>.
Regards,
Jörg
Craig L Russell schrieb:
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, x****calia******
//Service your Data!//
------------------------------------------------------------------------
*De :* Jörg von Frantzius
[mailto:[EMAIL PROTECTED]
*Envoyé :* mardi 14 mars 2006 12:20
*À :* [email protected] <mailto:[email protected]>
*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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
