Re: How to avoid database deadlocks?

Janne Mattila wrote:

>      >Your case would be simple if it were read only. However, it's not
>      and that makes it complex. This isn't unique to EJB or solved
>      magically by EJB or any other
>      >technology (with the possible exception of some AI driven design
>      tool). This is basic concurrency and a classic case of deadlock as
>      explained in any introductory text
>      >on database design.
>
>      If this is a complex case, I am really interested in seeing a simple
>      case. Two views - one shows cd and related artist and the other shows
>      artist and related cd's. How is this complex?
>
Both artist and related cd's are being updated in a single transaction.
Try it in sql.

>And this _is_ unique to
>      EJB. There would not be any updates to the database unless EJBs were
>      used. Using EJBs is the cause why ejbStore() gets called at the end
>      of transaction even when no updates have been made.
>
>
The BMP bean contract states that ejbStore is called whenever the
container needs to sync the bean with the persistent store. You're free
to *not* update the db if you don't want. EJB isn't causing you to
perform unneccessary updates, your bean code is doing that. If you want
to have the container deal with updates, use CMP.

>      >As I said above, EJBs don't remove the worry of transactions. They
>      offer declarative transactions. That may not seem like much with a
>      single database in an non
>      >clustered server. Add multiple data sources and clustering and it's
>      quite a lot of complexity hidden behind the bean interface.
>
>      You were not talking about declarative transactions, but demarcating
>      transactions manually with JTA. You don't need EJB's for that. If you
>      end up writing transactions yourselfs with JTA, why use EJB's with
>      the added complexity when you could just use JTA separately.
>      Clustering? That is not part of EJB specification.
>
>
Clustering isn't mentioned in the EJB because it doesn't impact or alter
the container, bean or client contracts. It's to be implemented in a
transparent way. The spec is definitately written with clustered and
distributed systems in mind.

>      >>>Programming is all about trade offs. Following patterns blindly is
>      never
>      >>>a good idea.
>      >>I agree. What was the part where I was following patterns blindly?
>      >By assuming that a session facade with one overall transaction was
>      the only useful pattern.
>
>      Oh come on. How is the example I mentioned not suitable for session
>      facade pattern? If that is not, then what is? Have you suggested a
>      better alternative? Or do you just like preaching?
>
>
>
I have already explained that it's one large transaction over many
domain objects. What you haven't done is explain why one transaction is
required by your use case, with the exception of some hand waying
argument about ACID.

--Victor

===========================================================================
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".