marc fleury <[EMAIL PROTECTED]> wrote:
>Following the wars and all...
>
>I did the 2 stage factorization but.... It all boiled down to the fact that
>the old architecture did not really distinguish between a CMP Persistence
>manager and a BMP persistence manager. (they were final plugins as in Jaws
>and BMP). And this was reason why 2tier seemed simpler than 3tier.
>
>As Dan and juha advocated the 3 tier solution acknowledges the difference
>between "store" and "persistence manager". The CMP PM is the "container
>persistence manager" and it takes care of ALL the callbacks to the instances
>before firing the pure "storing" operations. These operations are now in
>the PersistenceStore interface and CMPPersistenceManager (that both closely
>mimics the old EntityPersistennceStore) and JAWS and File are extensions.
>The factorization is done.
>
>The CMP persistence manager takes the return of create (previously void) as
>the key generated by the store. In clear the only thing that the store
>needs to do is return that primary key and the container deals with it.
>
>The "hookup" procedure is slightly changed in ContainerFactory.java
>
>Finally I would like to say that activate still reaches the store (even
>though it is pure EJB) to allow for the context setting by the plugin (jaws
>uses it for smart updates) so that it is a good place to do it.
Sorry to respond to this a month later - all this happened while I was
on holiday, and I'm still catching up on mail from that time.
What currently happens in JAWS on activate is that it creates a *new*
(and empty) persistence context. This is not the right thing to do!
Passivation should save the persistence context, and activation should
restore it. Then the calls relating to activation and passivation
wouldn't need to come to JAWS. (Alternatively, we should get rid of the
persistence context. It is only used for 'tuned' updates and 'read only'
entities, neither of which is required by the EJB spec. I'm all for
keeping things simple until they are working properly...)
The fundamental problem here is that if the bean context is extensible,
the passivation/activation mechanisms must recognise any extension.
>
>All right it is in CVS, compiles, runs the tests it used too which means
>that it is still broken
>
>I STILL HAVE TO FIX THE CVS LIKE I PROMISED LIKE WEEK,
>
>regards
>
>marc
>
>
>________________________
>Marc Fleury
>Chief Technology Officer
>Telkel, Inc.
>________________________
>
>
--
Justin Forder
