cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: RequestLifecycle components
Date Wed, 22 Oct 2003 16:13:36 GMT
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?  You can't (or at least shouldn't)
rely on recycle() being called--even in a pooled environment.

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.

Do not rely on recycle() for any transactional boundary or you *will* find your
application malfunctioning under load.

-- 

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


Mime
View raw message