Thanks for your replies. I agree that Tomcat should be responsible for all objects that are configured in Tomcat, and the web app should be responsible for objects that are created by the webapp. Currently it does not happen properly in tomcat. This is not related to DBCP code, it is all Tomcat code.
In terms of listeners, I saw that Tomcat executes requests while in the closing process. This may mean that after the context listener closed the pool, a new request will cause it to initialize again. We had a similar problem of things being created after shutdown started, and there are many permutations of listeners and sequences to test. Lots of debugging to do here. This again is irrespective of the listener which I am sure is closing the connection pool, it is a tomcat lifecycle issue. > It is built into Tomcat. Just read the docs for JDBC DataSources: > http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html I am talking about something else. Basically the XML is short: <GlobalNamingResources> <Resource auth="Container" .... type="javax.sql.DataSource" propertiesFile="database_pool_configuration_file.properties" /> </GlobalNamingResources> No configuration in XML other than JNDI related bindings. > My understanding was that: > > 1. Tomcat does not remove the connection pool > 2. Once the shutdown process has started, no new requests will be > handled by the currently-shutting-down context > > Could these two items give the result you are observing? It's easy > enough to have your webapp close the DataSource (even though it's kinda > stupid that Tomcat doesn't do it for you). That depends on which shutdown it is. Understanding 2 is not correct from my debugging. You can have a sequence of: 1. Connection pool closed 2. Request sent to servlet This happens during tomcat shutdown and will trigger a new connection. I suspect that similar sequence exists during redeploy. I cant recall exactly what happened in this case, but I remember that it was in more than one scenario. We decided to shut down tomcat every time and forget about it, even though we do have a listener that closes pools, along the same lines as the listener that you wrote I imagine. If you want to add a listener that closes the pool, I would try adding tomcat lifecycle listener to the context. You can handle event Lifecycle.AFTER_STOP_EVENT. Try both listeners (web app and tomcat) and see which one runs last, and put the code there. You have higher probability of catching an open connection if you do it later. If the listener is configured via tomcat and not the web app, you also get a configuration that each party is responsible for cleaning up its own bugs, as opposed to web app cleaning up tomcat bugs. Then the vision of J2EE designers of "separation of roles" materializes :) Elli --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
