Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 23091 invoked by uid 500); 5 Dec 2002 02:39:00 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 23051 invoked from network); 5 Dec 2002 02:39:00 -0000 Message-ID: <3DEEBC27.6010303@itmedicine.net> Date: Wed, 04 Dec 2002 18:38:31 -0800 From: Greg Weinger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [SHOWSTOPPER?] cocoon sources no longer thread-safe References: Content-Type: multipart/alternative; boundary="------------070108010900030701040608" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --------------070108010900030701040608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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. > > Ok, I have a better understanding of ThreadLocal variables now. Would you mind giving a quick example of how to do this? I've been poring over the source, but I'm not sure I'm on the right track: //code run by PooledThread public void run() { Environment env = CocoonComponentManager.getCurrentEnvironment(); Processor proc = CocoonComponentManager.getCurrentProcessor(); CoccoonComponentManager.startProcessing(env); CoccoonComponentManager.enterEnvironment(env); doStuff(); CoccoonComponentManager.leaveEnvironment(); } As far as thread safety goes, I know my own code doesn't have ThreadLocals, but I don't know where else in the Cocoon machinery they might lurk. Thanks for your help, Greg --------------070108010900030701040608 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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.

Ok, I have a better understanding of ThreadLocal variables now.

Would you mind giving a quick example of how to do this?

I've been poring over the source, but I'm not sure I'm on the right track:

//code run by PooledThread

public void run() {

Environment env = CocoonComponentManager.getCurrentEnvironment();
Processor proc = CocoonComponentManager.getCurrentProcessor();
CoccoonComponentManager.startProcessing(env);
CoccoonComponentManager.enterEnvironment(env);

doStuff();

CoccoonComponentManager.leaveEnvironment();
}

As far as thread safety goes, I know my own code doesn't have ThreadLocals, but I don't know where else in the Cocoon machinery they might lurk.

Thanks for your help,
Greg
--------------070108010900030701040608--