cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
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:
>>
>>    
>>
>>>Hi,
>>>
>>>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
>implementation.
>  
>

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="my.app.MyThreadLocalPropagator"/>
  <propagator class="my.app.ExternalLibThreadLocalPropagator"/>
</thread-pool>

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

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



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message