tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Miles" <>
Subject Re: finalize question
Date Thu, 03 Nov 2005 10:23:04 GMT
Andy Kriger wrote:

> Thanks for the info. A followup question...
>"The second one is where the application has ThreadLocal data that is
>attached to a container thread. In tomcat this thread will be part of
>the thread pool, so it will never be garbage collected."
>We use ThreadLocal to handle our Hibernate Session. In
>ServletContextListener.contextDestroyed, I call a destroy method on
>the class doing the handling that cleans up the Hibernate Sessions and
>nulls out the ThreadLocal. Will this allow it to be gc'd or will
>Tomcat still hold onto a reference?

The static HibernateSession Singleton class is instated under the 
WebappClassLoader, and its ThreadLocal object is part of the webapp. 
Providing there are no bugs in Hibernate and it doesn't reference any 
object loaded by StandardClassLoader everything should be ok.  If you 
can prove a reference please post.

The problem arrises where:

WebappClassLoader -> TheadLocal -> someObjectGraphThatReferences -> 

or some object graph that references some other object instated under 
StandardClassLoader.  Every instated object has its class loader 
associated with it, a hidden implicit association.

I find ThreadLocal an annoying implementation, as I would like a 
privileged implementation of ThreadLocal that has the right to 
read/change another thread's value (and therefore null out its 
reference, obviously at a high performance cost).  Sort of like 
ThreadLocal.set(long threadId, Object null);

I'm looking at some open source profiler tools, to see if they can be 
altered to give a report specifically on ClassLoader ownership of object 

Darryl L. Miles

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message