Re: Proposed new Java feature
"Robert Klemme" <shortcutter@googlemail.com> wrote in message
news:a2ehm0Fee8U1@mid.individual.net...
2. ThreadLocals interact badly with ThreadPools, because the ThreadLocals
keep their value when the tyhread is put back into the pool. This can
lead
to leaks and even potential security issues.
I would actually consider this good interaction with thread pools: the
local stays around for as long as the thread lives. If you introduce
security issues this way than you are probably not using thread locals
properly. There are two things that you generally need to consider with
thread locals which both result from the fact that the life time of a
thread local value extends across a current method call (i.e. earlier and
later):
OK. Now, coinsider these two cases (for, say, a webserver):
1. I create a new thread to handle each new request.
2. I optimize (1) by using a thread pool to minimize thread creation.
I want those two to behave identically (other than performance). To acheive
that, I need to be able to kill all the ThreadLocals when putting the
Threads back into the pool for later reuse. Otherwise
A. The ThreadLocals for threads in the pool cause packratting.
B. A reused thread contains context created during its previous use. This
may be context that the user correspnding to the request currently being
handled by the thread should not be able to see.