Carsten Ziegeler wrote: > > We added in 2.1 several lifecycle extensions to the ones > already provided by > Avalon: > The request lifecycle, the global request lifecycle and parent aware. > > While it seems to be possible to support the two request > lifecycles in 2.2 (with fortress), I currently see no real > way to support parent aware (but perhaps there is a way). > However, I think we should avoid adding our own lifecycle > interfaces whereever possible. > > So, let's think about them: > > ParentAware > ----------- > Has been introduced to have a cleaner implementation for the > selectors used in the sitemaps. I think/hope this is not an > issue with fortress anymore. So, unless ParentAware is needed > somewhere else, we could remove it. The implementation is > always tied to a specific container which makes moving to > another one more difficult. >
+1 for removing it. I see no use for it anymore with the componentized processor. > > 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. Unico
