Interesting idea, really ! But I suspect it might break some things in some cases. I'm thinking about cross-context requests (where the requestDispatcher calls another web application in the same JVM with the same thread). If the context-specific table changes when dispatching the request to the other context, the latter won't see any threadlocal variables bound by the first context. I feel it might be problem for some webapps or some frameworks, but I cannot provide a concrete example. Maybe it's not a problem after all...
Sylvain On 29 avr. 2010, at 23:57, Caldarale, Charles R wrote: >> From: Caldarale, Charles R >> Subject: RE: Need advice to notify StandardExecutor when a webapp is >> stopped >> >> This is an area where some byte code modification might be appropriate >> in a container environment, so that the ThreadLocal behavior could be >> modified to be "ContextLocal" instead. > > Thinking about this some more, byte code modification of the ThreadLocal > class would not be needed. When a thread returns to the pool, any > ThreadLocal objects it has could be moved to a context-specific table, using > an MRU stack. When a thread is taken out of the pool to process a request > for a context, it could then move the most recent set of ThreadLocal objects > to itself. The context-specific table would be discarded whenever the webapp > is stopped. This would allow performance acceleration for each webapp, and > avoid pollution of the pool. > > - Chuck > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
