>What does transaction isolation got to do with this? We are talking
>about different locking schemes, not transaction isolation (which has to
>do with what data to read when; interesting subject, but not relevant
>here).
IMHO transaction isolation is a lot more relevant here than the
optimistic vs pessimistic locking comparisons you keep drawing.
You seem to be stock on how the container does/does not perform
locking where as the discussion is much more relevant at the
database level since that's what most containers opt to delegate
concurrency control to.
>>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.
>"optimistic locking" and "exclusive" are hard to use in the same
>sentence. With pessimistic locking there are no exclusive locks. That's
>why its optimistic...
>(am I missing something obvious here, or!?)
I'd say so. "Exclusive lock" (xlock) is not taken by user, it is granted
by resource manager when an update operation is to proceed.
>>Similarly TX2 is waiting to acquire a shared lock on resource A but it
>>must wait for TX1 to commit.
>Similarly, the word "wait" is also unnecessary when talking about
>optimistic locking. There is no waiting, which is why there is no
>contention with optimistic locking, and which is also why there can be
>no deadlocks with optimistic locking.
The wait is a blocking wait imposed by resource manager when another
transaction has been granted an xlock on a resource. It is not an
user initiated wait.
>>If you don't think that's a deadlock then I give in.
>That is a deadlock, but it is not optimistic locking. That is
>pessimistic locking by virtue of using the serialized transaction
>isolation level (note: if you use the serialized transactions level
>there can *only* be pessimistic locking regardless of what the app
>server does. But I assumed that we were talking about pessimistic vs
>optimistic in the general case here).
>>In practice, the resource manager will detect the deadlock
>>and choose to rollback one of the transactions. Hardly a desirable
>>outcome.
>Again, you are describing the serialized transaction isolation level,
>not optimistic locking. Different things.
No. I am describing the deadlock scenario that can occur with optimistic
locking.
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".
