On 21/12/2009 15:59, Mark Thomas wrote: > 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
This might be complete nonsense :) Konstantin's comments about the JDBC-ODBC bridge got me looking at this more closely. There was a bug in the de-registration code that mean it was a little over-zealous on its clean up. Patch to trunk and proposal for 6.0.21 to follow shortly. With the patch in place, your original code should work happily. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
