On 03.07.2009, at 14:20, Carsten Ziegeler wrote:
Alexander Daniel wrote:
On 03.07.2009, at 10:41, Carsten Ziegeler wrote:
Alexander Daniel wrote:
Does somebody know why ThreadLocal is used in
PoolableProxyHandler [1]
for the componentHolder in Cocoon 2.2?
Sure :)
Whenever components are taken out of the pool they need to be put
back
somehow, so they are available for other clients again.
We use a thread local which is cleared when the request finishes,
so all used components get back into the pool.
Thanks for the answer Carsten. What you describe is done by the
destruction callback mechanism of Spring. But why can't we simply
use a
direct reference [2] to the component? Why is a ThreadLocal used as
key
to the component?
Hmm, not sure if I understand you correctly.
The poolable factory returns a single instance to spring which is the
proxy - spring has no knowledge of poolable components.
Therefore the proxy together with a thread local is used to internally
forward the method calls to instances from the pool. There is a
separate
instance per thread - otherwise you would run into multi-threading
issues as the same instance would be used across requests.
PoolableFactoryBean [2] creates a new PoolableProxyHandler instance
[1] for each pooled component used in a pipeline, i.e. it will not be
shared across different requests. Therefore I do not understand the
use of ThreadLocal.
Alex
[1]
public Object getObject() throws Exception {
return Proxy.newProxyInstance(this.getClass().getClassLoader(),
this.interfaces,
new PoolableProxyHandler(this));
}
[2]
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java
