cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [2.2] Proxies for pooled components
Date Mon, 14 Feb 2005 22:41:08 GMT
Carsten Ziegeler wrote:

> Sylvain Wallez wrote:
>> Carsten Ziegeler wrote:
>>> Sylvain Wallez wrote:
>>>> First question, but not the one you expected ;-)
>>> :( ;)
>>>> Can you explain what these proxies are for exactly? Is it to avoid 
>>>> lookup/release at each usage? If yes, how/when are the components 
>>>> actually put back in the pool (sorry, not much time to look at the 
>>>> code ATM)?
>>> Oh, sure, totally forgot about it: yes, the proxies manage the 
>>> lookup/release. When you look up a pooled component, you get a 
>>> proxy. The first time, you invoke a method on this proxy, the real 
>>> component is looked up inside proxy and then used. The component is 
>>> stored locally in the proxy and the proxy uses a thread local 
>>> variable. So if different threads use the same proxy, they get 
>>> different instances. If there were two lookups, two proxies are 
>>> created and each proxy has its own thread local.
>> And what if there are several lookups for the same role within the 
>> same thread? Is the same component used? 
> No no, it is not - these are different components.
> > That may lead to strange behaviours
>> with stateful components (and if they are pooled, it's because they 
>> are stateful), as the state will be shared between the different 
>> usage locations of the component, which are very likely to not know 
>> each other.
> As these are different components, I don't see a problem here.
>> This is certainly an interesting feature, but I'm not sure it will be 
>> usable with that many components.
>> WDYT? Do you have some uses cases?
> Sure: developing an own thread safe component that uses other 
> components. With proxies you can simply lookup all components in the 
> service() method and use them.
> Without proxies you can lookup other thread safe components in 
> service() but pooled components have to be looked up each time they're 
> used.

I see. So there's a different proxy returned at each call to lookup(), 
and that proxy has its own ThreadLocal to track actual components. IIRC, 
Hivemind provides this. Don't know about Spring, but it certainly could 
be done with a custom BeanFactory.

> So this simplifies component development. And as I indicated, it also 
> opens the road for constructor/setter based injection as injected 
> components need to be thread safe.

I remember of some people having some OutOfMemoryError exceptions when 
using some RequestLifeCycle components in complicated pipelines 
involving many subrequests, because the RLC components weren't released 
even if they actually were no more useful. Automatic pool management may 
lead to the same kind of problems, don't you think?

Or what we need is that the proxy tracks some methods that indicate end 
of use of the proxied component that can then go back to the pool before 
the end of the request (e.g. connection.close() or 

But all this will complexify a lot the small CoreManager and I'm 
wondering if this is a good idea to write yet another dependency 
injection container when some widely used ones already exist. Ask Ugo, 
which one he prefers ;-)

> Usually pooled components are not thread safe, proxied pooled 
> components are.

Yup. Cool.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message