On 25/03/2011 17:53, Paul Gifford wrote: > We're having a disagreement in the office about the JNDI datasources. We're > running Tomcat 6 and using the built-in DBCP as our connection pool. DBCP > is configured in the server's context.xml. Our webapp gets a datasource > using JNDI via Spring JDBC. > > There are two schools of thought on the team. One says we should close the > datasource in a listener's contextDestroyed, something like this: > > ((BasicDataSource)datasource).close(); > > The other school of thought says that's not necessary, since Tomcat is > managing the data source and the resource is not instantiated in the > listener's contextInitialized method. > > What's the right answer? I haven't seen anything that says one way or the > other.
There are two parts to this: 1. closing the datasource 2. de-registering the JDBC driver For 1, it is not necessary. Stopping the app makes it eligible for GC. However, Tomcat 7.0.11 onwards does stop it (see [1]) since this forces the database connections to be closed immediately rather than waiting for GC. Since this is viewed as a 'nice to have' rather than a bug (it is not a memory leak) then it won't be back-ported to earlier versions. 2. is absolutely an application responsibility. If the app doesn't do it Tomcat (at least 7.0.x and recent 6.0.x) will complain loudly about the memory leak and then de-register it for you. The argument for this being the app's responsibility is that the app triggered the registration (by including the JAR with the JDBC driver in the web app) therefore the app must clean it up. Both of the above assume an application defined data source. HTH, Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=25060 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
