On Fri, 24 Jan 2003, Chris Brown wrote:
> Date: Fri, 24 Jan 2003 10:54:38 +0100 > From: Chris Brown <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
