Hi folks,
I'm working for middle-ware/corba project in Fujitsu Limited.
I have some opinions regarding Entity Beans which is specified
in EJB 1.0. For example, on
1) Concurrent access to Entity Beans
2) Transactional behavior of Entity Beans
3) Cached state management
I know the above three issues, which were not supported by EJB 1.0
sufficiently, were discussed in this mailing list as below.
-- Regarding 1), We realized that EJB 1.0 specification has
no support for optimistic concurrency control.
-- Regarding 3), in many applications, we recognized that keeping
the data around on the middletier for long period was needed.
I consider that the three issues 1)-3) are great important.
So, I would like to reopen the discussion here.
First of all, I attached my understandings and opinions on the three
shortcomings of the current EJB specification to this e-mail.
I would greatly appreciate your comments on them.
-----
Best Regards
Yasuaki SUGINO
FUJITSU LIMITED
=====
1. Concurrent access to E-Beans
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EJB 1.0 does not support concurrent access to an E-Bean. Instead, it relies
mostly on the concurrency mechanism of the persistent store. This is not
sufficient, and the two options a container provides:
(1) multiple copies activation
(2) serialization of accesses on a single instance
These can lead to inconsistencies and update conflicts (in 1) and to poor
performance due to excessive access limitation (in 2). Both cases amount to
delegating concurrency control to the persistent store.
1.1 Multiple E-Bean instance activation, or store-enforced serializability:
This is a transaction-level concurrency control that activates one instance
per transaction. The idea is to rely on the transaction synchronization in the
DB, which typically enforces serialization. There are problems with this
model:
-- It is tied to the transaction control of the persistent store. Yet, EJB
supports non-transactional access modes (TX_NOT_SUPPORTED, TX_SUPPORTS).
In these cases, no support is provided for concurrency.
-- It is not realistic for handling concurrent updates. Indeed, this is
typically an optimistic concurrency control, where several clients can
update their own local copy, with the risk of inconsistent, conflicting
updates.
1.2 Container-enforced serialization:
Here, the container enforces itself the serialization of transactions on the
Bean. If the serialization is strictly enforced, we foresee the following
problems:
-- Deadlocks are possible when trying to serialize calls that generate nested
calls to another E-Bean method.
-- 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).
2. EJB transaction isolation modes are only for the persistent store
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Only the following situations are supported by EJB 1.0:
(a) the persistent store is transactional, the E-Bean also.
(b) Neither the persistent store is transactional (e.g. flat file), nor the
E-Bean.
In (a), a consistent coupling between the two states (memory, persistent)
requires the isolation levels to also apply at E-Bean level. For instance, if
READ_UNCOMMITTED is specified for an E-Bean, the expected behavior is that
dirty reads should be possible to any transaction accessing this E-Bean.
However, in EJB 1.0, because this is only enforced at database level, current
changes will not be visible until ejbStore() is performed.
Transaction isolation modes are only meaningful for the back-end store: the
container is unable to enforce them at E-Bean level, whether in harmony with
the persistent store policies, or in an autonomous way (e.g. if E-Beans are
transactional but not the store).
3. Cache management
^^^^^^^^^^^^^^^^^^^^
E-Beans may be complex business objects that require complex mappings to the
database. They also may be used in long transactions. All this require more
support for managing their cached state - in addition to making these states
directly visible to higher level services (concurrency, locking, transaction,
authorization).
There is no support in EJB 1.0 for managing cached states, except their
synchronization with the database (ejbStore(), ejbLoad()).
Some caching Options (9.11.4) are suggested, but only in the context of
transactions. They need to be extended to support concurrency as well as
recovery.
One objective is to reduce the access to the persistent store. The overhead of
reading/writing a persistent store varies greatly depending on the store
technology, and on the complexity of the object state. In many cases, when a
transaction rollbacks, getting back to the previous - last committed - state
could still be done from the initial cache value, without re-read on the
database (if no more recent commit has been done). When a new transaction
starts on an E-Bean that is already in use, this E-Bean can be the source for
the last committed state.
===========================================================================
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".
