> All the other servers I know (IAS, iPlanet, SilverStream) use optimistic
> concurrency. This means that you won't have deadlock, but that you must
pay more
> attention to your transaction and DB isolation settings, and that you
might have
> more transaction rollbacks.
Optimistic locking cannot mean "you won't have deadlock." 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. 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).
One old technique used is to attempt to ensure modifications of objects
occurs in the same order everywhere. 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.
David
===========================================================================
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".
