[2.2] ThreadLocal use in PoolableProxyHandler

[Alexander Daniel]

Does somebody know why ThreadLocal is used in PoolableProxyHandler [1]  
for the componentHolder in Cocoon 2.2?

Thanks, Alex

[1] 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

[cziegeler]

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.

Carsten

> Thanks, Alex
>
> [1]
> 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
>
>


--
Carsten Ziegeler
cziegeler@...

[Alexander Daniel]

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?

Alex

[2] private Object component = null;


>>
>> [1]
>> 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
>>

[cziegeler]

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.

Carsten
--
Carsten Ziegeler
cziegeler@...

[Alexander Daniel]

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

[cziegeler]

Alexander Daniel wrote
>
> 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.
Yes, you're right for sitemap components - but this isn't true for any
other component. Imagine a singleton component using a poolable. The
singleton is used by multiple threads and therefore each thread
requires an own instance

Now, this is not optimal and actually it's legacy code - it is only used
for old Avalon components.

Carsten

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

--
Carsten Ziegeler
cziegeler@...