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?
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. Carsten
