Hi!
Dan OConnor wrote:
> 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.
These decisions are already handled in the
EntitySynchronizationInterceptor.
> 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.
If the code is refactored as have discussed, the process would be:
1. Container calls "ejbCreate" on instance
2. Container calls create on PM
3. Container calls "ejbPostCreate" on instance
Could the above be handled in the create-call in the PM. Or is it
absolutely necessary to do this after ejbPostCreate? It was my
impression from the spec. that what you refer to would have been
initialized after ejbCreate. ejbPostCreate is only used to setup
relationships to other beans (I think).
> 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? :-)
With the refactoring that we discussed this would still be possible. The
PM still has "storeEntity" in which it may perform this kind of checks.
> 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?
There might be reasons to add an additional layer, but I don't see the
above as such reasons. Would you agree?
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
