>>TX1 updates DB resource A, and waits on DB resource B
>>TX2 updates DB resource B, and waits on DB resource A
>>Deadlock.
>.. explain why TX2 in a DB using optimistic concurrency control needs to
>"wait" for resource A.
DB using optimistic concurrency control? I thought you were backing Victor's
call for a container managed OCC. Granted at the database level there can't
be any deadlocks without locks. You get conflicts at commit time and out of
N concurrent transactions, 1 is successful and N-1 are aborted. This is
also what happens when a deadlock is detected.
In any case, it is all academic what happens in the database kernel, what
matters in the real world, is that the callers will have to deal with the
exceptions raised because of deadlock or conflict.
I suggested before the best way to avoid deadlocks was to design orderly
access in the application and I am sticking with that.
===========================================================================
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".
