> Locks are never taken out in optimistic concurrency schemes.
Which implementation of that scheme are you talking about? I'm sure there
are pure optimistic solutions out there, but most commercial implementations
that talk about optimistic concurrency control do use locking during the
actual updates.
However, you are right that deadlock should be rare -- and in fact I've not
seen deadlock at all when done well, but I could easily imagine problems.
The reason is that the target objects to be updated can be read-locked by
the commercial DB implementations most used today, and only when all have
been obtained (pessimistic locking is used at the "last moment" just before
the updates) are the updates committed. If during the read-lock phase a
timestamp mismatch is noted, then you are right, the transaction is aborted
with a concurrency violation.
David
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
