Berin Loritsch wrote: > > Unico Hommes wrote: > > > > >> 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. > >> > > > > > > Hmm, AFAIU declaring a per-thread lifecycle is not enough, > the handler > > that implements this in Fortress is not aware of recyclable > > components. What it does is give out a different instances for > > different threads and the same instance for the same thread > that's it. > > There still needs to be some custom provision for handling > Recyclables > > our request type situation. But I know Berin knows more about this. > > > > Why would you recycle if you aren't pooling?
But I *am* pooling. What I meant was a situation where the same instance is handed out to the same thread until it is released. Then it can be put back into the pool again. > You can't (or > at least shouldn't) rely on recycle() being called--even in a > pooled environment. > OK. > The whole purpose of the recycle() method is to return the > component to an initial state *if* it is pooled and reused. > If the component is created and destroyed (SIngleThreaded in > old ECM parlance, or when the pool is overloaded), then the > recycle() method is never called once. And that is with > current ECM code. > I know. And so it doesn't make much sense to assign a poolable component with a per-thread lifestyle handler. > Do not rely on recycle() for any transactional boundary or > you *will* find your application malfunctioning under load. > OK. -- Unico > -- > > "They that give up essential liberty to obtain a little > temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > >
