On 21/12/2009 15:13, Rainer Frey (Inxmail GmbH) wrote: > On Monday 21 December 2009 15:23:42 Mark Thomas wrote: >> The memory leak is caused by the DriverManager implementation. It holds >> a reference to the Driver. If the Driver was loaded by the web >> application then the Driver holds a reference to the WebappClassLoader. >> This in turn holds references to every class it has ever loaded. This >> can result in a significant PermGen leak on application reload. >> >> All the methods I have looked at do auto-registration but never >> de-registration. Given how DriverManager works that is a guaranteed >> memory leak on reload. In certain circumstances you can rely on >> auto-registration but it is safe to register and deregister yourself. > > Thanks for the explanation, I understand now. > >>>> If you get a chance before I get to it later today, try using a context >>>> listener to register and de-register the driver when your app starts and >>>> stops and let us know how you get on. >>> >>> I implemented the ServletContextListener below, and I don't get any >>> exceptions anymore. >> >> That is exactly the sort of thing I had in mind. > > Our product is a tomcat server with several (up to 25-40) copies of the same > webapp (one for each customer). When this listener in one application would > kick in, no other would be influenced, right?
In your scenario, if the web app behaves the same way as the test case attached to the bug, you are likely to have issues. I think you'd need to use the container level lifecycle listener approach. > Actually each of those webapps can use one of 4 supported databases, but in > most installations only one driver jar is actually available. Would you > recommend this approach in this scenario rather than the context listener, or > is there a drawback? See above. For an example of a container level lifecycle listener take a look at this commit. That should give you the idea. http://svn.apache.org/viewvc?view=revision&revision=828196 Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
