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 ->
StandardClassLoader
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
graphs.
--
Darryl L. Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
