David Wall wrote:
> >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.
I understand how locks work. An yes, there are locks at the DBMS layer and
possibly in the EJB server. However, from the bean writer's perspective, the
system supports optimistic concurrency control and I don't have to look under
the covers. If your server vendor claims to support optimistic concurrency and
you end up with deadlocks, you need to find another product.
>
>
> 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?
>
We use a custom version of VBSF from Objectmatter that I modified for use with
EJB. The persistence layer I'm referring to supports mapping objects to
relational tables. As has been suggested many times on this list, we could have
ignored entity beans and handled all persistent storage via the VBSF framework.
Most queries in our system do bypass entity bean finder methods. However, I have
found that there is value in putting some business logic like validations in the
entity beans. And as I stated, using entity beans provides a pattern which helps
in avoiding deadlocks.
>
> David
--Victor Langelo
===========================================================================
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".
