Re: How to avoid database deadlocks?

[Victor Langelo]

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