"Lahooti, Hamid" wrote:
> >David Wall <[EMAIL PROTECTED]> wrote:
> >>>>Optimistic locking cannot mean "you won't have deadlock."
> >>>Yes it does. Deadlocks are prevented by keeping several versions of the
> >>>same instance (one for each tx), hence there will be no deadlocks since
> >>>two tx's cannot lock on the same instance.
> >
> >>No it doesn't. Consider the following scenario:
> >>TX1 updates A, intends to Update B, cannot see TX2's updates to B,
> >>TX2 updates B, intends to Update A, cannot see TX1's updates to A
> >
> >>If A and B could see that their intended record has been modified,
> >>they could rollback back (principal of optimistic locking) back but
> >>transaction isolation ensures they cannot see each others updates.
> >>Hence we have a deadlock situation.
>
> >And what does this have to do with optimistic locking? You are still
> >thinking in terms of pessimistic locking.
> >What matters is whether TX1 or TX2 commits first. If TX1 commits first,
> >then TX2 cannot commit since one or more record(s) that it has modified
> >was modified between the time the transaction was started and the time
> >it was committed.
> You seem to misunderstand how transaction isolation works.
> TX1 and TX2 are two different transactions.
> Optimistic locking:
> having modified resource A, TX1 must read the timestamp of resource B
> to establish whether it has been modified by another transaction,
> but the (as yet uncommitted)transaction TX2 has an exclusive lock on B.
>
> Similarly TX2 is waiting to acquire a shared lock on resource A but it
> must wait for TX1 to commit.
> If you don't think that's a deadlock then I give in.
>
> In practice, the resource manager will detect the deadlock
> and choose to rollback one of the transactions. Hardly a desirable
> outcome.
>
That was my whole point. The deadlock (better call this a conflict, because a
deadlock, by definition, is not detected and solved, else it wouldn't be a
deadlock) doesn't occur in the EJB container, but occurs at database level, and
causes a rollback. If you read my previous posts carefully, this is just what I
said : you won't have deadlocks (meaning, clients waiting endlessly), but
transaction rollbacks instead. The client has more work, but won't ever wait
endlessly. Moreover, the application will have the same behaviour whether it is
clustered or not.
JB.
>
> Regards,
> Hamid
>
> ===========================================================================
> 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".
--
Jean-Baptiste Nizet
[EMAIL PROTECTED]
R&D Engineer, S1 Belgium
Kleine Kloosterstraat, 23
B-1932 Sint-Stevens Woluwe
+32 2 200 45 42
===========================================================================
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".
