On 11 Jul 00, at 8:36, Rickard �berg wrote:
> Agree, with the addition that I have changed my mind and would rather go
> with Marc's suggestion to put this code in EntityContainer. Since there
> is (AFAICT) only one way to implement these callbacks it doesn't seem
> necessary to have it in a separate place, which would introduce more
> complexity to the code.
Hi Rickard,
I wanted to suggest a couple of examples where the three-layer
solution would be useful (entity container->persistence manager-
>object/relational mapper).
1. Although for the most part, the callback methods must be
invoked according to the specification's finite state machine, the
invocations of ejbLoad and ejbStore are flexible, and policy
decisions might be made. An example of this in the current code
is the "read-only" test, where a request to load an object's state is
ignored unless a certain amount of time has passed, and a request
to store an object's state is always ignored. These policy
decisions shouldn't be in the entity container, but apply equally to
all object/relational mapping schemes.
2. A particular persistence-management scheme may require
additional private callbacks that are not part of the specification.
An example of this might be an implementation of EJB 1.1 CMP
that wants to wrap collection classes to provide lazy loading and
tuned updates of dependent objects after the invocation of
ejbPostCreate (the first point at which the object's identity is
available) but before the invocation of any business methods.
These invocations shouldn't be hard-coded to the entity container,
since they are not generally applicable.
3. It's possible that users of the jBoss container may desire non-
compliant optimizations that would require changing the callbacks.
For instance, they may want us to check an "is-modified" method
for BMP beans, and not call ejbStore if it returns false. This is not
compliant, but what can you do if your fans are screaming for it? :-)
Rickard, you have a better sense of the trade-offs involved in
factoring out a third layer of code (rather than the two you are
currently advocating). I'd appreciate your feedback--are these
points worth considering, or is code simplicity the overriding value
in this particular case?
-Dan
>
> There are a few places that needs to be changed:
> * For create the EntityContainer should do ejbCreate, and handle the BMP
> and CMP cases differently. Then call PM (which may be an O/R mapper),
> then call ejbPostCreate. The EntityContainer should be responsible for
> hooking up the instance with a EJBObject from the ContainerInvoker
> before returning.
> * For finders the PM should be responsible for returning one or more
> primary keys. Again, the EntityContainer hooks up these with EJBObjects
> before returning
> * Two methods, activate() and passivate() should be added to
> EntityContainer (and StatefulSessionContainer) which call the PM and
> then ejbActivate, and ejbPassivate and the PM (respectively). The caches
> should be changed to call the EntityContainer to ask for
> activation/passivation instead of calling the PM directly.
>
> I think this should be enough. This would provide a good refactoring of
> the code, and will make it easier and less error-prone to code PM's.
>
> Thanks to Marc and Juha for catching this and providing an interesting
> (although a bit heated) discussion on the subject.
>
> Sounds ok? Marc, if you agree (and I think you do), can you please make
> the above changes?
>
> regards,
> Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
