cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [SHOWSTOPPER?] cocoon sources no longer thread-safe
Date Wed, 04 Dec 2002 08:55:22 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>Carsten Ziegeler wrote:
>>>there were some problems with multi-threading and the environment
>>>stack which should be fixed by last monday - at least that's
>>>what I thought.
>>>However, there is one subtle thing to keep in mind:
>>>ThreadLocal and InheritableThreadLocal variables!
>>>The current environment stack uses a InheritableThreadLocal
>>>variable - so you have to make sure that if you
>>>create/use a different thread that this InheritableThreadLocal
>>>variable is initialized correctly.
>>>Especially when you use thread-pools you have to
>>>manually set this variable (contained in the
>>>CocoonComponentManager) whenever you take a thread
>>>out of the pool and use it.
>>>Is it possible, that your problems are related to this?
>>If the problem is related to some (Interited)ThreadLocals which haven't 
>>the proper value, what about providing a ThreadPool component in Cocoon 
>>that cleanly manages these values, so that applications requiring thread 
>>do not have to wonder about it ?
>Yes, I was thinking about this , too. So, go on: +1 :)
>But theoretically (turning panic mode on), this problem is much
>bigger: You have to know about each library (component) you use, if
>this component uses ThreadLocal variables and how they are used.
>Only if you know this, you can make a safe thread-pool

My proposal may help to get out of the panic ;-)

If this is a component defined in cocoon.xconf, and provided that you 
know which libraries use ThreadLocals, then you can write a specific 
implementation of that component for the libraries you're using.

We can even imagine this component being a holder for 
ThreadLocalPropagators :

public interface ThreadLocalPropagator {
  /** Get the value in the source thread */
  public Object getValue();
  /** Set the value in the target thread */
  public void setValue(Object value);

<thread-pool class="o.a.c.c.thread.GenericThrealLocalPropagatorPool">
  <propagator class="o.a.c.c.CocoonThreadLocalPropagator"/>
  <propagator class=""/>
  <propagator class=""/>

This way, you just plug in the ThreadLocalPropagators needed by your 

Going even further, we can have auto-discovery of ThreadLocalPropagator 
implementations by searching META-INF/services/ThreadLocalPropagator 
resources in the classpath (just like what JAXP does to get a parser or 
a transformer) : just drop a library with the proper service definition 
in WEB-INF/lib and you're done.

Thoughts ?

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

To unsubscribe, e-mail:
For additional commands, email:

View raw message