On Tue, 25 Jul 2000 09:48:42 -0700, 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.
> I agree that it
>reduces your chances because locks are held for less time (all large-scale
>online transaction processing -- OLTP -- systems have used optimistic
>locking), but it cannot prevent deadlock.
There is no difference between optimistic and pessimistic locking with
regard to the duration of the locks.
> If two transactions come with an
>update, one doing Object A then Object B, and the other updating Object B
>and then Object A, you can have a deadlock (it can even be worse than that,
>such as transaction 2 updagint objects B->C->D->A).
No, this is incorrect, since transaction 1 will get his copy of A and B,
and transaction 2 will get another copies of A and B. If both
transactions make changes to the data and wish to commit, the one that
commits last will fail. This is what optimistic locking is all about:
"Do no locking during the transaction, and resolve all problems at
commit time, possibly rolling back". Just as the previous poster noted
this will lead to more rollbacks, which are not due to some error, but
rather due to normal processing of concurrent transactions.
>One old technique used is to attempt to ensure modifications of objects
>occurs in the same order everywhere.
This is only relevant if pessimistic locking is used.
> If objects A and B must be updated,
>then do A before B all the time and you won't have deadlock. This is a good
>strategy in that it handles a large percentage of the problem, but it's
>generally impractical as systems grow and there is more than one service
>using the same objects. The interactions among objects can be quite complex
>and make this impossible to know with any certitude. Like the above
>example, the coder of Object D was correct in updating Object A, but Object
>D cannot know that it will be called by Object B through Object C.
As you will have noticed by now your understanding of how optimistic
locking works is incorrect.
If you do not agree with the above, please provide your understanding of
what optimistic locking is, so that we can compare the differences with
what I have described.
regards,
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".
