Re: How to avoid database deadlocks?

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