>For all intents and purposes, the persistence layer and databases I use
achieve optimistic concurrency control
>without fear of deadlocks. This is achieved through careful design of the
persistence layer and sticking to doing
>all updates with entity beans. A given object or object graph is only
updated by a single entity bean and that
>bean always performs the updates in the same order. I use a relational DBMS
which locks rows on writes (for
>instance Oracle). All writes happen at the end of the transaction during
the ejbStore phase. The duration of all
>locks is on the order of a few milliseconds. In addition, the persistence
layer checks for update conflicts in the
>write operation so both are in the same atomic operation. Given all these
facts, I don't stay up late at night
>worrying about deadlocks.
I agree with your strategy overall since it's the practical one based on how
databases really work. This was the point of my original post when I talked
about doing optimistic/pessimistic using the application's control. The
fact that the DB still does locking was the key to my original argument, and
when there are locks, there can be deadlock. This true despite what you do
since locks are only released when a transaction is committed (or aborted),
not when the ejbStore completes. So, if CLIENT 1 starts TRAN 1 and does an
update on EB A, then EB B, and CLIENT 2 starts TRAN 2 and does an update on
EB B, then EB A, you can run into deadlock conditions if TRAN 2 gets EB B
just before TRAN 1 does.
Considering you mentioned using entity beans, what do you mean by a careful
design of the persistence layer? Isn't that layer provided by your EJB
container? And if you wrote another persistence layer, then why EJBs?
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".
