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?
All your cases are variations on the theme that two different types of EJBs are
instantiating the same data. I think the EJB spec should DEFINE that when using
such beans in the same transaction there should be no interaction between the
instantiations, in other words each gets the data fresh from the database and
neither sees the changes made by the other. Anything else would be terrible, as
EJBs could apparently change value without a method being called. This
definition needs to be extended to say what happens during COMMIT if both
instantiations of the data have changed. Ideally the transaction should simply
be backed out, but implementing this could be problematic. I think that at
present the only practical rule is that it is undefined. I would not expect an
application normally to need to do it anyway.
However finders should clearly find EJBs that have already been instantiated in
the transaction, so finders need to look into the cache. There should be no
leeway in the EJB spec for servers to screw this one up.
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".
