> We are using Echidna (http://www.javagroup.org/echidna/) to run many
> different tasks inside a single VirtualMachine. The different threads
> can run on their own, but they need to communicate with a coordinator,
> running in the main thread.
Interesting, never heard of it. So is it like a J2EE container without
J2EE ;-) ... I should check it out.
>> // thread starts (or a "worker" thread is checked out of the pool) //
>> obtain/create DC, bind it to the thread
>> DataContext context = ...
>> DataContext.bindThreadDataContext(context);
>>
>> ....
>>
>> // Somewhere in the middle of thread processing...
>> // This call retrieves context previously bound to
>> // the current thread from anywhere in the thread call stack
>> DataContext context = DataContext.getThreadDataContext();
>
> Does the bindThreadDataContext() method do something special, or could
> be enough to store the dataContext in an instance variable of the
> object we use to fork the thread?
Nothing special. It uses a ThreadLocal variable
(http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html) to
store DataContext for the thread. So as long as your instance variable is
not shared across the threads, it should be the same thing.
Andrus
This archive was generated by hypermail 2.0.0 : Fri Dec 17 2004 - 13:48:04 EST