>> -- Deadlocks are possible when trying to serialize calls that generate
nested
>> calls to another E-Bean method.
>
>Which is why the tx timeout is very important to solve such deadlocks
>(besides getting rid of them by design). Transactions which are deadlock
>prone should be put into while-blocks to ensure that they got done in
>the event of a deadlock:
Servers should detect and break deadlocks. We throw a DeadlockException to
the party who's call was interrupted when the deadlock was broken. The
caller can then catch and possibly retry the operation without loosing the
transaction. Relying on transaction timeouts and while loops is a workable
solution only when there is no support from your server. Of course, the best
remedy against deadlocks is a good design :-)
>> -- Long transactions are blocking other accesses; in particular "read"
>> accesses, with no reason. We do not want to block an E-Beans for
read when
>> another client writes it and has not committed yet. (non-blocking
writes
>> are typically provided by database vendors like Oracle).
>
>Just a hunch: would it be possible to mark the bean as "TX_REQUIRES" but
>mark those methods not needing tx:s ("read":s) as "TX_NOT_SUPPORTED"?
>Would that yield a "non-blocking read"-effect?
It depends on your transaction isolation setting for the db.
Imre Kifor
Valto Systems
===========================================================================
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".
