cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: RequestLifecycle components
Date Wed, 22 Oct 2003 16:40:57 GMT
Unico Hommes wrote:

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

I agree that not all components will be able to make the transition from
pooled to Per Thread.  However, some of them will.  For example, the
Generators, Transformers, and Serializers are not going to make the transition.
However, if there are any components declared per-request without any
requirement from the interface (i.e. no precise order of method calls required),
then those could make the transition.

However, I think the RequestTerminationQueue will be a good solution for
the end of request guarantees for ending database transactions or releasing
all of these components.  It would probably work much better than what we
have now.

Granted, it would lengthen the time the server is officially processing a
request, but the user does not perceive it because the response was already
sent.  Then again, we can just pop all of those commands onto the global
command queue once the request is done and all of that "post processing" is
done outside the critical path.  Either way, we have options.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

View raw message