cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: RequestLifecycle components
Date Wed, 22 Oct 2003 15:05:13 GMT
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├žade 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


Mime
View raw message