"Lahooti, Hamid" wrote:I think I was giving you more credit than you deserve. I
don't know
> whether it's your English or real lack of DBMS understanding here but
> it seems to me you have the wrong end of the stick. You don't even
> seem to know what a database resource deadlock is and how it comes about.
> Once again:
>
> TX1 updates DB resource A, and waits on DB resource B
> TX2 updates DB resource B, and waits on DB resource A
>
> Deadlock.
>
> Now is that really that difficult for you to grasp?
>
> Regards,
> Hamid
>
I thought I'd jump in here with some defence for Rickard, because this thread is
increasingly distressing.
The whole reason for using optimistic concurrency is that the server/transaction
DOES NOT BLOCK. EVER. It assumes optimistically that the records touched by a
transaction are not going to be touched by any other. When asked to commit, the
server checks to see if this original assumption is still valid. That is, if
another transaction updated the timestamp or version of one of the records, the
original transaction fails with an optimistic concurrency exception.
Locks are never taken out in optimistic concurrency schemes.
Because there are no locks and there is no blocking, there cannot be a
deadlock. The term "optimistic locking" is a misnomer, given the generally
accepted use of the term "lock". "Optimistic concurrency scheme" is appropriate.
I'm sorry Hamid, but hopefully you'll give a little more credit to Rickard in
the future before ticking him off.
-Sriram
===========================================================================
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".
