Dan OConnor wrote:
> > 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.
Yes, I think so.
> 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.
Well, the EntitySynchronizationInterceptor handles how to synchronize to
and from the database, so I think this one falls into that category.
> 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?)
We should have an option for it, yes. However, I used the following
motivation for what goes where: there are two things here, *if* we want
to store and *how* to store. Read-only and commit options and get*
optimiziation (-> read-only) are variants of the "if" case, and could be
handled outside of the PM. Once we have decided that a store should
indeed occur, there are a number of ways that could happen, and which is
what the PM does. AFAIK, all the "if" variants can be used with any PM
variant, so that also hints that it should be outside of a PM. Would you
agree?
> 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.
How do you mean "copy"? If you want to make a modified/enhanced ESI you
mean? I think we could simply change ESI to be more subclassing-friendly
or similar to allow more functionality to be added. Make it pluggable
even. :-)
> 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.
If the ESI is made pluggable this could be one plugin for that. That's
not going to be trivial to do though.
> 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! :-)
Hm, well, this particular one falls into the "if" of stores, so
theoretically it should go into the ESI. Either we just put all the
stuff we want to have in there and make configurable options to turn
them on/off, or we make ESI pluggable. For now I would go with the
former for simplicity.
> 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. :-)
Heh, no problemo, these were all good points :-) Some refactoring of
code seems to be the result of this.
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
