Ian McCallion wrote:
>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.
And what if the client program that initiated a "short" transaction
hangs in the middle of it? Same problem.
The only way to really enforce short transactions and to avoid long
database locks, seems to exercise transaction control at server level
only: no client-controlled transactions. Since EJB supports client
transactions, and databases also allow for long transactions,
I would tend to think that *some* applications really need that.
Such is the case when complex business objects are manipulated interactively
(e.g. purchase or service orders , or also product data, CAD, CAM, etc.).
More generally, one of my concern with application server technology
is that if it lags too much behind the level of Service provided by
DBMSs (e.g. in concurrency control),
then developers may prefer to bypass the middle tier to directly
implement an ad-hoc server on top of the database. All is needed for
EJB, at spec level, is not to redefine a full service (say concurrency
control), but just the hooks & control info that will allow one to plug in.
>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.
Typically, a transactional call to a session bean may end up
invoking/accessing more than one entity bean.
So here again these entity beans will be locked until the final
commit . If the transaction is distributed,
the session bean may even not commit in the same call.
So here again it may be helpful to know what kind
of access (read or write) is performed by method calls, so that some
concurrency may be supported during not-so-short transactions.
There is another problem: the transaction isolation modes in EJB
1.0 have absolutely no meaning at container level: they are only
significant for the back-end database, which is confusing.
The container is currently unable to enforce these at entity bean
level. For example if a user specifies "Serializable" mode, a
container that deals with concurrency by replicating e-bean instances
will not detect conflicting updates. Similarly, if "read-uncommitted"
is specified (or even read-committed), a container that uses
exclusive lock will not be able to allow dirty reads.
------------------------------------------------------------------
Jacques Durand e-mail:[EMAIL PROTECTED]
T.D.I. (Technology Deployment International)
5000, Old Ironside Drive Santa Clara, CA 95054, USA
Tel: (408)330-3411 Fax: (408)330-3444
------------------------------------------------------------------
