Chip Wilson wrote:
>For any optimization, there is an underlying assumption. The assumption
here is that database selects occur >only in finder methods. I can think of
three other scenarios in which selects occur within an EJB transaction:
>
>1) In ejbLoad. I have always favored designing the component model so that
the object graphs of entity beans >are mutually disjoint. Others have
argued that this restriction is unnecessary. If the data associated with an
>entity bean instance is not disjoint from the data associated with every
other entity bean instance, then any >call to ejbLoad from within a
transaction could select data that has been updated as part of that
transaction. >Since the container controls
>calls to ejbLoad, the same optimization could be performed. Now it would
be "Call ejbStore on all entity beans >associated with a transaction before
calling any finder method or ejbLoad method".
>
>2) Lazy initialization. For entity beans with bean managed persistence,
some argue that the bean may defer >loading some of its state until it is
required; i.e. until someone asks for it. Since this could happen as the
>result of calling any transactional method on a bean with bean managed
persistence, we now have "Call ejbStore >on all entity beans associated with
a transaction before calling any finder method or ejbLoad method, or before
>calling a transactional method on
>an entity bean using bean managed persistence".
>
>3) Session beans. It has been argued that session beans should sometimes
access the database directly using the >current transaction context. Any
transactional method on a session bean could potentially do this, making our
>optimization "Call ejbStore on all entity beans associated with a
transaction before calling any finder method >or ejbLoad method, or before
calling a transactional method on an entity using bean managed persistence
or >before calling a transactional
>method on a session bean".
>
>Are there other scenarios?
An automatical handling of all these problems by the container would indeed
lead to bad performance
because of "oversynchronization". So it seems that in the case of BMP (and
in session beans) the bean
provider should have the responsibility (and possibility) to force a
synchronization. What do you think
of the following suggestion?
The bean provider should be able to force a synchronization of all entity
beans involved in the current
transaction. This method should be callable from business method of session
beans and entity beans with
BMP. In the case of CMP the container provider should be responsible for
synchronization before executing
a finder method in the context of an already existing transaction. If the
suggested new "sync()" method
would not find it's way to the specification, synchronization should
automatically be done by the container
in case of BMP too.
Dirk.
===========================================================================
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".
