On Wed, 26 Jul 2000 12:02:55 +0100, Lahooti, Hamid
<[EMAIL PROTECTED]> wrote:
>You seem to misunderstand how transaction isolation works.
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).
>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!?)
>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.
>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.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
