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? > > But I'm not sure about this thing. Are drivers required by spec to > > provide a public parameterless constructor, and is it safe to create and > > manage instances of a Driver on my own? > > Most do, but it doesn't appear to be required. In your circumstances, > you could use a LifecycleListener defined at the container level that > just called Class.forName(String). In that scenario the common class > loader would load the driver (as now) but it would also be the context > class loader so DriverManager would pin the common class loader in > memory which is not an issue (since it is never reloaded). In this case > the memory leak protection code wouldn't kick in on webapp reload and > all would be fine in your app. 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? Thanks for all your feedback on this, Mark. This is a great service to us! > Mark Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
