On 11 Jul 00, at 19:43, Rickard �berg wrote:
> 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.
Hi Rickard,
Yes, some policy decisions are handled in
EntitySynchronizationInterceptor, but the one I cited--the read only
test--is indeed currently handled by JawsPersistenceManager.
Perhaps this too should be moved to
EntitySynchronizationInterceptor. On the other hand, there is
something to be said for keeping separate the core functionality
related to transaction boundaries and commit options, from more
funky options such as read-only beans.
Another example of functionality that I might move to a persistence
manager layer would be the non-standard optimization currently
hard-coded into EntitySynchronizationInterceptor that doesn't store
the entity if the business method's name starts with "get." This
would make the average programmer happy, but could actually
break specification-compliant code. (Regardless of whether or not
we move it, we should have the option of turning it off, yes?)
I agree with you that this could all be handled in
EntitySynchronizationInterceptor, and there are advantages to this.
The disadvantage is that writing an interceptor that works with
these options requires the developer to copy the very core commit-
option functionality to the new version of an
EntitySynchronizationInterceptor.
> 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).
Here's the scenario: A relationship to other entity beans is set up
by the bean developer once the identity is available. The bean
developer's collection class needs to be wrapped so that the
container can track (for instance) additions and deletions to the
list, or invalidation of the list in the case of a subsequent ejbLoad.
This isn't a particularly important example, though, with the EJB
2.0 container-managed persistence model solving this particular
problem more elegantly. Consider this line of the discussion
dropped.
>
> > 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.
Yes, this would still be possible. It could go in either the
EntityContainer or the object/relational mapper. I was addressing
your point that there was only one way to implement the callbacks,
and so they might as well go in the EntityContainer.
They can still go in EntityContainer, and perhaps they should. But
it's not so obvious to me which way is correct. If someone might
want to write an alternative (e.g. Weblogic-emulation-mode for the
is-modified), I thought our philosophy was to provide a plug-in that
made it easy to do so. I don't want that person mucking up your
work in EntityContainer, nor do I want two branches of the code
that have duplicate core functionality. (Putting the code in the
object/relational mapper isn't good either, of course. You can use
"isModified" if you are using CocoBase, but not TopLink? That will
leave them scratching their heads.)
On the other hand, we can't give people a plugin for every possible
change anyone might ever want to make. Where do we draw the
line? Maybe here...
I'm interested in hearing your response, and since I'm asking for it,
Marc can't get mad that you are arguing trivial points endlessly! :-)
Anyway, you understand this chunk of code, whereas I skim
through it to figure out what's going on. Thanks for your patience if
I'm being an idiot. :-)
-Dan
>
> > 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
>
