Hi, after a lot of work I got it working, I think so. Java's ThreadLocal and
InheritableThreadLocal classes are totally new for me and I haven't used them
before.
With the help of JDK 5.0 API I made my own class containing a static variable
of type InheritableThreadLocal. Then, everytime I create my thread
I store "the global data" (in the call method) in the variable of type
InheritableThreadLocal and get it as well. It was still very difficult to test
does it work right
because I'm using a thread pool which reuses older threads. But I guess this
InheritableThreadLocal variable should work in the right way even if it's
shared with all sessions and
threads (because of that static variable).
Thank you guys!
Juha
>>> [EMAIL PROTECTED] 08/17 1:51 >>>
Hi,
Solution is purely dependent on your requirements and the scenarios.
If you are not using the thread pools:
- Install a handler on your request path.
- Maintain a InheritableThreadLocal with this handler.
- Set the session to this thread local variable whenever a request is received
by this handler.
- Expose a method to get the session - getSession.
- Now the main thread and all its child thread can access this property.
But if you are using thread pools, then the problem is complicate. And the
possible solution is
- Maintain a Inheritable thread local variable i.e. property store in every
component or taskwhich can be started in a new thread.
- Modify the thread pool in such a way that any parameter can be passed to the
thread pool.
- Use this parameter to set the thread local variable of the task i.e. the
component, after starting the task in a thread.
- This may help you to get the access for this property.
Thanks
Mohit.
>>> [EMAIL PROTECTED] 08/17 4:30 >>>
You can get access to the MessageContext in your threads IF you put it
there yourself instead of depending on the static method
MessageContext.getCurrentContext(). Having invoked that method where it
works (the thread handling the web service request), you can place the
result in a thread local of other threads.
That is, if your thread lives for the processing of a single request,
you can copy the message context reference to it when you create the
thread. Otherwise you copy it to the thread each time it starts
processing a request.
Jeff
Juha Kononen wrote:
>Thanks for advise!
>
> Too bad that it's not possible to get an access to MessageContext in
>user's own threads.
>Does this mean that the session mechanism can be used only partially in
>axis (because there is no
>way to get HttpSession in threads)? I had an idea to use HttpSession as
>a global variable in each session where to
>store session-specific information (data sent by a client) for each
>client. This global
>session-specific storage would help me to get data directly instead of
>passing it
>to objects and threads via many function parameters (in contrast to
>HttpSession I use ServletContext as a global variable
>for storing a reference to a database pool). Of course, I could get the
>data sent by a client via a static class variable
>in my DSServiceSOAPBindingImpl class. But unfortunately class variables
>are shared with all sessions, so that will not work if
>I want my class variables to be session-spefic. So is there any way I
>can use a global, session-specific variable anywhere in
>my server-side code (including those threads)? Java doesn't have global
>variables, but don't we still need them? :)
>
>Juha
>
>
>
