Yasuaki SUGINO wrote:
> -- 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).
Transactions should never be designed to be long. At least, not "long" in the
sense that they spans human interactions - it is neither what the human wants
nor what the computer wants. For the human, think what happens if the
transaction aborts - everything, except the human, will back out. (Actually,
come to think of it, she may backout too, though in a different way). For the
system, think what happens if the human goes to lunch - database locks will be
hanging out indefinitely.
Design your transactions to be short and use a stateful session bean to
maintain continuity over a series of human interactions. Use a reliable EJB
server to ensure that the session beans do not get lost and cause your users to
back out.
Ian McCallion
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
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".
