Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <dev@cocoon.apache.org>
Subject: RE: RequestLifecycle components
Date: Wed, 22 Oct 2003 17:05:13 +0200
Message-ID: <LKENJPKDAIKAPKHEOCMMEEFBFMAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <84F0A43A4248CE45B5C0E20F4C40779C6008EF@naomi.webworks.nl>
Importance: Normal
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Unico Hommes wrote:
>
> Carsten Ziegeler wrote:
> >
> > Berin Loritsch wrote:
> > >
> > > I'm running into an issue here with RequestLifecycle components.
> > > I want to
> > > write the handler and such, and we can assume one handler to one
> > > component definition (configuration, etc.).  Right now the helper
> > > classes assume we have access to a Role.  This is not the case.
> > >
> > > I believe we can simplify things a little, but we cannot assume we
> > > have acess to the role.  I will let you know when I am done
> > with this
> > > issue, but if someone has any hints, help to offer, etc.
> > let me know.
> > >
> > If you need help, just let me know.
> >
> > I'm really thinking more and more that we simply should drop
> > RequestLifecycle and GlobalRequestLifecycle. Why?
> >
> > In most cases they are not used for the lifecycle of the
> > component but for the lifecycle of the data the component acts on.
> > You can achieve the same thing now by using the
> > o.a.c.components.persistence.RequestDataStore which is imho a
> > cleaner solution.
> >
> > Now, the advantage of the RequestLifecycleComponent is performance.
> > If you have several places during a request where this
> > component is used, only one instance of a RLC is used, which
> > means the data it acts on is only fetched once as well.
> >
> > If you use a Poolable component with the RequestDataStore,
> > this component is retrieved several times and several times
> > the data is fetched from the store. And exactly this last
> > point, fetching the data from the request is a little bit
> > more costly. Hmm.
> >
>
> What about transactional components? I have a situation where I
> use a GRL to wrap a session fa=E7ade type object and rely on
> recycle() being called at the end of the request in order to
> commit/rollback work done. How would I achieve this without GRL lifecycle?
>
Good question! Actually, I don't know and I'm wondering if it
is a good idea to rely on this behaviour of the component
container. Hmm, don't know.

Ok, anyway, we could keep the GRL which can be modelled in
fortress using a thread component (one component per thread),
but skip the RLC which caused a lot of trouble to get it
working and which might still cause us more trouble than
it's worth.

Carsten