Thanks for that great answer! I'm hoping you could help clarify my understanding and answer some more questions that your response brought up...
Based on the behavior you specified of ThreadLocals sticking around after the webapp is undeployed, is it correct to say that the thread pool you mentioned is global to ALL webapps in Tomcat, rather than multiple thread pools, one for each webapp in the same Tomcat instance? Is it also correct to say that this could be a security problem, where a user in another webapp could inadvertently see something left around in a ThreadLocal from another user in the same webapp - or from another user in a different webapp? Do you see any problems with creating one or more ThreadLocals as the first operation in the first filter defined for a webapp, and closing them (i.e. nulling them out) as the last operation in that same filter? This would thereby ensure that the ThreadLocal is there for the entire scope of the request. Do the garbage collection problems you mentioned apply in this case? (This next question is more to see whether my thought process is correct rather than to bash the servlet spec or Tomcat.) I can understand how any context listener methods aren't guaranteed to be called in the same thread as a request, because it's a completely unrelated concept. But am I correct to say that it's a limitation that session listeners (both attribute-binding and creational listener methods) aren't guaranteed to be run in the same thread as the request that created it? After all, each of those operations happens directly because of and "in" a given request, so wouldn't it be a better design for those methods to be called by the same thread? That way, you could use ThreadLocals to obtain values in the session listeners that are inserted elsewhere in the same request that created/invalidated a session, or bound/unbound a session attribute. Caldarale, Charles R wrote: > >> From: lightbulb432 [mailto:[EMAIL PROTECTED] >> Subject: Re: Is ThreadLocal safe to use in servlets >> >> A different way of asking this question is where/when >> does Tomcat start the Thread that handles a given >> request, and what is executed in the context of that >> thread? (e.g. filters, listeners, other things, servlets >> of course) > > Tomcat utilizes a thread pool for processing requests; the same thread > is used for the duration of the request through the entire > filter/servlet chain (required by the servlet spec), including data base > and other external resource access. However, since the threads are > pooled, you can't count on ever seeing the same thread twice in a given > servlet, so ThreadLocal objects are best created and destroyed during > individual request handling; trying to keep them around longer runs the > risk of their continuing to exist even after a webapp has been stopped > or undeployed, resulting in garbage collection problems. > > Since Listeners are not associated with a specific request, there's no > guarantee that the thread running through any Listener code will ever be > used for a request for the associated webapp, and there's no guarantee > it won't. > > - 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. > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Is-ThreadLocal-safe-to-use-in-servlets-tf3858168.html#a11270259 Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
