Re: How to avoid database deadlocks?

[Victor Langelo]

Janne Mattila wrote: Now, one could think about fiddling with transaction settings, maybe fetching data for record r1 could be done in a separate transaction to fetching data for corresponding artists A1. Maybe user would not care if a1 shows modifications by another transaction while r1 does not. Maybe that would be quite a rare condition. Or maybe that's not acceptable or wanted at all? The bottom line is that using (at least to me) very intuitive and common practises you still end up with concurrency problems using EJBs, even in this naive case. I was a bit surprised about this actually. And am curious, is this "expected" and normal behaviour, or should I have done something differently. And I am not buying into that I should have demarcated transactions somewhere else than the session facade, or that I should even have to spend lot of time thinking about transaction handling in such a simple case to get it "working". EJB supports declarative transactions. You still have to think about transactions. You still have to declare where and what type of transactions you want. What seems to be forgotten is that good patterns are more than an code design or sample code. They should describe when the pattern is applicable. The trade-offs and typical results of using the pattern. What parts may be altered without breaking the pattern. And any known uses of the pattern. 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. Does your use case really require ACID qualities? Or is the use case really a repetition of a another use case B? Use case B may need ACID qualities even if the original use case doesn't. For instance, take generating invoices for recently shipped orders. The use case would generate invoices for all recently shipped orders which haven't yet been invoiced. This is essentially an iteration over a generate invoice use case for a selected set of orders. Does it matter to the original use case if invoice n fails? Probably enough to generate an error message, but not enough to rollback all the successfully created invoices. That's a good thing to remember, when you have certain use cases that would cause long transactions. Separate methods for each piece (negating the performance benefits of session facade)? There's no significant loss of performance using Requires New. Deadlocks are the ultimate in lost performance. Of course deadlocks are severe performance hit, but you cannot say that starting and committing n transactions would the same performance-wise as starting and committing 1? If there are n updates in n transactions or n updates in 1 transaction the performance will be about the same for most modern databases. The cost of a transaction is proportional to the amount of work performed during the transaction. Besides, I was speculating about a situation where facade.getDataForArtistAndRecord() would be split to separate methods facade.getDataForArtist() facade.getDataForRecord() there's of course the added remote calls, which the session facade was meant to minimize (my original point). Handle transactions inside one method manually by JTA (lose the benefits of automatic transaction handling in EJB)? How is automatic transaction handling being lost by adding explicit demarcation? Calling setRollbackOnly explicitly isn't that hard. Yes, I would guess it's not that hard. Using EJBs brings a lot of added complexity to your project. For one entity you have to have several source classes, several deployment descriptors, more complexity to the deployment process, debugging etc. As you pay that price, you get something in return - you do not have to worry about transactions, security, distribution etc. as much. That's the whole point of EJB's. If you have to give up those benefits to get your project working I would whether using EJBs is worth the price that you have to pay. 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. Using UserTransaction doesn't cost you anything except being able to declare transaction settings at bean deployment time. You don't lose 2 phase commit, declarative security, clustering or any other benefit of EJB except decarative transactions for one bean.   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. --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".