> From: Patric Rufflar [mailto:pat...@rufflar.com] > Subject: ThreadLocals, context listeners and classloader leaks
> It's unspecified in the servlet spec 2.5 if a servlet context > listener is allowed to take the use of ThreadLocals during > contextInitialized(). I have no idea what the phrase "take the use of" means; what are you trying to say? Any thread can make use of ThreadLocal, but in a thread pool environment, it's usually silly to do so, unless you're very, very careful. > Is this (also) allowed in tomcat? Tomcat makes little effort to prevent stupid programmer tricks. > Because ThreadLocals are inherited from its parent threads ??? A ThreadLocal is _not_ inherited from the parent thread, although the _value_ of each InheritableThreadLocal is copied to a spawned thread. > the inherited ThreadLocals are still there and reference to the > original values - and will most probably remain in the spawned > threads forever Which is an example of why you must be very, very careful in your use of ThreadLocal in a pooled environment. > Is the main thread usage for context initializers intended? Yes. In Tomcat 7, you can have parallel initialization, but not in Tomcat 6. Read the docs for <Engine> and <Host>. > What's the best way to deal with this situation (especially > if the avoidance of ThreadLocals in context initializers is > not an option)? Why is it not an option? Even if your code calls some 3rd-party package to do its work, you can clean up the mess created before returning from the initializer. > Wouldn't it be better to create an individual thread for (each) > context initializer to avoid these kind of problems? Tomcat can't work around every possible programming silliness. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
