Re: [2.2] Proxies for pooled components

[Sylvain Wallez]

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 
contenthandler.endDocument())

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
--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }