>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.
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".
