Am 26.01.2012 16:59, schrieb Caldarale, Charles R:
No; again, a ThreadLocal is _not_ inherited, but an
InheritableThreadLocal is. These are different animals.
1. A InheritableThreadLocal is (extends) a ThreadLocal.
2. Surprise: A InheritableThreadLocal is _not_ used for the
Thread.inheritableThreadLocals field/mechanism when creating a new
thread
(at least not in oracle jdk 6, see Thread.class source for details) -
for this, a ThreadLocal.class instance is used, too.
So the statement "we have more than one ThreadLocal which references to
value A" seems correct to me.
Why can't they be removed? (The code to do so is ugly, but readily
findable with Google.)
I think you mean by traversing all threads and do some reflection
actions on them?
Please note that I already included feasible workarounds into my
projects - so for me, this issue is not a show stopper anymore.
But:
The intention of my original mail was to highlight the problem with
ThreadLocals/Context initializers and to suggest an improvement to
tomcat to prevent
others from falling into this pit.
Secondly, from an economic perspective such an improvement in tomcat
would be much cheaper than to include such hacks inside all the projects
all over the world.
Again, that would fix _one_ stupid programmer trick, out of the
uncountable number of potential errors.
I am interested in these disadvantages.
What kind of potential errors do you see if an individual thread would
be used for each context initialization?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
