"matthew.hawthorne" <[EMAIL PROTECTED]> writes:
I'm not sure if this is it -- but ThreadLocals don't work inside of app servers that use thread pooling.
that's news to me. care to clarify this?
perhaps you mean that for a series of requests coming as part of a
single session, the several requests aren't guaranteed to be serviced
by the same thread. which is true, but a far cry from "ThreadLocals
don't work inside app servers using thread pools".
Here's what I meant:
In servers that use thread pooling, ThreadLocal variables may not be unique for each request.
I was using ThreadLocals to store invocation information, specific to each request. But I noticed that, in some requests, instead of the intialValue() method being called to initialize the ThreadLocal, it was simply getting the already-initialized value. After doing some further investigation and checking Thread.currentThread() and such, I realized that the same Thread was being used for multiple requests, which eliminated the uniqueness for each request that I needed to maintain.
Like I said in my earlier email, my technique was overly complicated. I was able to solve the problem by using Axis' MessageContext.getCurrentContext().
But you're right -- after re-reading what I wrote, I realized that I had phrased it terribly. ThreadLocals were working exactly the way that they're supposed to, I just didn't understand the way that the server managed its threads.
