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
