You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Chris Brown <br...@reflexe.fr> on 2003/01/24 10:54:38 UTC
Re: Memory leak with ThreadGroups -> and other stuff
Quick follow-on question for Craig...
If you put a JDBC driver in your webapp's /WEB-INF/lib directory, then as
that gets registered with DriverManager, what happens when you reload a
context? If the DriverManager maintains a reference to the Driver loaded
with the webapp classloader, that must surely cause a few problems for
cleaning up the classloader...
Should this sort of problem disappear with
"DriverManager.deregisterDriver()" ? Are there other pitfalls of this sort
in the standard Java APIs (I'm thinking of some classes with factory methods
and "helpful" internal caching of instances created via such factory
methods...)
- Chris
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
Sent: Friday, January 24, 2003 1:49 AM
Subject: RE: Memory leak with ThreadGroups
> If your application is well behaved (i.e. it doesn't have classes in
> common/lib or shared/lib that maintain references to things loaded from
> the webapp), then this will cause the entire webapp to become garbage. If
> *any* references to *any* classes inside the webapp still exist, though,
> then essentially nothing from your webapp can be collected.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Memory leak with ThreadGroups -> and other stuff
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 24 Jan 2003, Chris Brown wrote:
> Date: Fri, 24 Jan 2003 10:54:38 +0100
> From: Chris Brown <br...@reflexe.fr>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Memory leak with ThreadGroups -> and other stuff
>
> Quick follow-on question for Craig...
>
> If you put a JDBC driver in your webapp's /WEB-INF/lib directory, then as
> that gets registered with DriverManager, what happens when you reload a
> context? If the DriverManager maintains a reference to the Driver loaded
> with the webapp classloader, that must surely cause a few problems for
> cleaning up the classloader...
>
Probably.
> Should this sort of problem disappear with
> "DriverManager.deregisterDriver()" ? Are there other pitfalls of this sort
> in the standard Java APIs (I'm thinking of some classes with factory methods
> and "helpful" internal caching of instances created via such factory
> methods...)
>
It might, but there's no way to know without seeing the source code to the
driver itself. It might have other live references lying around.
I tend to think of my JDBC driver as part of the system software, and put
it in common/lib (so it doesn't get reloaded). This is required anyway,
if you're going to use the JNDI data source support in Tomcat.
> - Chris
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>