> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Justin Forder
> Sent: Tuesday, August 15, 2000 5:59 PM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] 3 tier persistence
>
>
> marc fleury <[EMAIL PROTECTED]> wrote:
> >
> >> > [ Justin wrote]
> >>
> >> >> The fundamental problem here is that if the bean context is
> extensible,
> >> >> the passivation/activation mechanisms must recognise any extension.
> >> >
> >> >which is why it should be done by jaws and not the container or
> >> the manager
> >> >(PersistenceManager).. this is "store" specific, not
> "manager" specific.
> >>
> >> OK - so how does JAWS get at the passivation store? (as opposed to the
> >> persistent store, which JAWS *is* responsible for)
> >
> >Sorry I wasn't clear...
> >
> >JAWS is *not* responsible for the "passivation" and "activation"
> operations
> >in their whole.
> >JAWS is just responsible for the "putJAWSContext" in the
> "storeContext" of
> >the EnterpriseContext.
> >
> >In that respect (and that is what I explained in the first mail) we still
> >need the "callback" to jaws to say "I am (the container) activating this,
> >but you take care of your jaws specific information (tuned updates are
> >specific to JAWS).
> >
> >Is this clearer?
> >
> >But maybe I missed your question...
>
> We are both focusing on the same issue.
>
> The way I look at it is: passivation/activation have to act on *all* the
> state of an enterprise bean - i.e. the 'business' state plus any bean-
> specific state required by the other services within the EJB server.
>
> The Memento pattern seems to fit: JAWS has some state that it needs to
> associate with the bean, and the passivation/activation service just
> needs to treat this as a "blob" that can be safely placed on backing
> store and brought back to memory when needed.
>
> Two requirements:
>
> 1. passivation/activation must know where to find these additions to the
> context, and
>
> 2. passivation/activation must know how to store/load them.
>
> At present, the persistence context is accessed via
> getPersistenceContext and setPersistenceContext methods on
> EntityEnterpriseContext. In other words, it is hard-coded. It would be
> better if EntityEnterpriseContext contained a Map of "context facets",
> and if the whole thing was serializable. Then passivation would store
> the whole lot, without having to involve JAWS (or any other service),
> and activation would bring it back into memory, again without having to
> involve JAWS.
>
> Does that make sense?
no. I don't get it. pattern talk.
but I might be out of my depth :)
marc>
> regards
>
> Justin
>
> --
> Justin Forder
>
>
