On 8/31/2010 1:21 PM, Caldarale, Charles R wrote:
It seems to me that using static ThreadLocal's isn't going to
save that much overhead vs. just creating a regular local object
each time you run.
The above is even more true in modern JVMs with method inlining and escape
analysis - such an object might not even be created on the heap, just on the
stack and immediately discarded when the method creating it returns.
There are plenty of other use cases for thread locals -- and there are
cases where it is not desirable to do the try { /* add and use thread
local */ } finally { /* remove thread local */ } pattern. To
interoperate with a container like Tomcat one then has to provide init()
and destroy() methods for one's library -- and provide these methods
with knowledge of all thread locals throughout one's entire library. Yuck!
That said, I can see that Java's ThreadLocal implementation gives some
containers little to no choice. Thus a really good library should
provide such hooks. Tomcat clearly has a choice, however, of replacing
threads in a pool as they become idle -- and thus as a really good
container it should be so nice :-)
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
