tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <>
Subject RE: Is ThreadLocal safe to use in servlets
Date Sat, 23 Jun 2007 21:28:19 GMT
> From: lightbulb432 [] 
> Subject: RE: Is ThreadLocal safe to use in servlets
> 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?

Normally, there's a thread pool per <Connector>.  Tomcat 6 introduces
the ability to share thread pools across multiple <Connector>s, via the
<Executor> element.  (I haven't tried it.)

> 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?

Yes, that's another reason to restrict the lifetime to that of a single
request.  Exposure across webapps would be difficult to exploit unless
the class definition of the object cached via ThreadLocal were visible
to both webapps.

> 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? 

Should be o.k., and there's shouldn't be any GC impacts.

> 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? 

AFAIK, there's no guarantee, since the servlet spec doesn't appear to
require it.  I haven't looked at the Catalina code to see how such
Listeners are actually invoked, but it would seem rather risky to count
on the same thread being used.

> 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?

Such a requirement might be better from performance reasons, but it
would be restrictive on the container implementation.  After all,
ThreadLocal is an abusable nicety, not an intrinsic characteristic of
servlet processing.

 - Chuck

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:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message