-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul,
On 3/25/2011 1:53 PM, 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. Interestingly enough, I'm on both sides of the fence on this one. Here's why: On the one hand, I maintain that since Tomcat creates the DataSource, it should destroy the DataSource. On the other, the Java EE spec says that JNDI resources should be created each time they are looked-up. This was very surprising to me, especially for JNDI DataSources. Of course, this makes much more sense in the context of, say, a JNDI Mail Session. See bugs https://issues.apache.org/bugzilla/show_bug.cgi?id=49994 and https://issues.apache.org/bugzilla/show_bug.cgi?id=50159. So, if you follow the spec (always the right answer, IMO), then your webapp is expected to close the DataSource. In this particular instance, though, the spec-defined behavior seems entirely impractical. Tomcat is very unlikely to be modified to change this behavior, so you should probably go ahead and write a ServletContextListener that does nothing in init() and closes the DataSource in destroy(). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2M6VIACgkQ9CaO5/Lv0PBPYgCfXqRx4wm2L6B7uYULMGl4g9+D OD0AoJny+glkOZhRbGyk2a1FpFbKJKcm =wE5c -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
