cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: [RT] The future of our lifecycle extensions in 2.2
Date Thu, 08 Jan 2004 12:36:36 GMT

Carsten Ziegeler wrote:
> 
> Unico Hommes wrote:
> > >
> > > RequestLifecycle
> > > ----------------
> > > 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. This was 
> > > basically the initial use case. In fact, the implementation is a 
> > > little bit tricky or someone might call it even hacky. The 
> > > implementation is tied to a specific container.
> > >
> > > You can achieve the same thing now by using the 
> > > o.a.c.components.persistence.RequestDataStore which is imho a 
> > > cleaner solution as it doesn't require to change the 
> container. So 
> > > with this solution we are container independent.
> > >
> > > Currently, you look up during the request the 
> > > RequestLifecycleComponent whereever you need it and get the data 
> > > from this component. So, this is one lookup per data access.
> > >
> > > With the RequestDataStore it's basically the same. You lookup the 
> > > store once (it's thread safe) and look up during the request the 
> > > data object from the store. So again, this is one lookup per data 
> > > access.
> > >
> >
> > I am not in favor of this ATM, because I think there are some use 
> > cases that can't be covered by the RequestDataStore approach. In 
> > particular there does not seem to be a way to release a 
> component once 
> > at the end of a request.
> >
> > A third party database vendor we work with provides access 
> to its API 
> > through a so called Session object. Such a Session object has the 
> > following characteristics:
> >
> > - A thread can 'join' only one Session at a time.
> > - A Session instance can be 'joined' by only one thread at a time.
> > (single threaded)
> > - All database access (read/write) must be done within the 
> scope of an 
> > open transaction.
> >
> > Now consider a pipeline where multiple components need 
> access to the 
> > database, for instance both the generator and the transformer. 
> > According to the previous Session characteristics they need 
> to use the 
> > same Session instance. Upon first access the Session needs to be 
> > joined and a transaction needs to start, upon last release 
> the session 
> > needs to be 'left' and the transaction closed.
> >
> > I've currently accomplished this by having a Recyclable 
> > GlobalRequestLifecycleComponent wrapper for a Session that 
> joins and 
> > begins during component setup stage and that leaves and closes at 
> > recycle time.
> >
> > Unless there is a different way to cover this and similar 
> use cases I 
> > think we should keep at least global request lifecycle component.
> >
> The data, hold by the request data store is auto-released 
> when the request ends. For example, if your data object 
> implements dispose(), then this method is called.
> Does this fit your needs?
> 

OK, I think this covers my case. I'm going try it.

> You can't rely on the fact that recycle() is always called on 
> your component.
> The current implementations ECM and Fortress, don't do this 
> under heavy load.
> The approach using the request data store is reliable.

Woah, that is good to know. Is this considered a bug? I don't think I
ever experienced a problem with this.

Regards, Unico


Mime
View raw message