Carsten Ziegeler wrote:
Sylvain Wallez wrote:My proposal may help to get out of the panic ;-)
Carsten Ziegeler wrote:Yes, I was thinking about this , too. So, go on: +1 :)
Hi,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 ?
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?
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.
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
