Re: How to avoid database deadlocks?

[Victor Langelo]

Janne Mattila wrote:

Ugh,

I could not really follow your point about separate transactions.

- If you do not want transactional access to data, what's the point of
using EJB's?

I'm not talking about giving up transactions. Just changing their scope.

- This is not a pessimistic transaction with WebLogic & Oracle


It is from the database perspective. Oracle doesn't actually support
optimistic locking, but a hybrid they call optimistic.
- A usual design pattern is to wrap handling of a use case behind a session facade which demarcates the transaction.

That's fine, but what's the use case the requires changing all artists
and their records in one transaction? The use case is the point of my
question.
If you mean to separate handling of a use case into different pieces with their own transactions (and forget that you lose ACID qualities of the use case) how would you implement that?


Either use BMT in your session bean or give the entity bean methods the
Requires New transaction attribute. Which method you use depends on the
contents of a single transaction.
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.
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.
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.
Programming is all about trade offs. Following patterns blindly is never
a good idea.
--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".