Why do connections persist when I undeploy a webapp using the Tomcat 7 JDBC connection pool?

Question

I've got a minimal Spring webapp deployed to Tomcat 7.0.22 - it consists of a couple of pages, a controller, a service, and a DAO which has one method that runs a SELECT query.

The webapp is configured to use the new Tomcat JDBC connection pool - here is the resource configuration in the webapp's context.xml:

<Resource name="jdbc/myDB"
          auth="Container"
          type="javax.sql.DataSource"
          driverClassName="oracle.jdbc.OracleDriver"
          url="jdbc:oracle:thin:@blah blah"
          factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
          maxActive="15"
          initialSize="5"
          maxWait="40000"
          validationQuery="select 1 from dual"
          removeAbandoned="true"
          removeAbandonedTimeout="300"
          logAbandoned="false"
          username="user"
          password="pass"
          testOnBorrow="true"
          validationInterval="30000"
          timeBetweenEvictionRunsMillis="60000"
          minEvictableIdleTimeMillis="60000" />

When I deploy the webapp I see 5 connections appear (querying v$session from SQL Developer). When I undeploy the webapp the connections persist (in state WAITING). Each time I redeploy my webapp, 5 new connections show up.

It appears the pool is still hanging around - and the "Find Leaks" button on Tomcat's manager app tells me the app is leaking memory.

How do I get rid of the pool when the webapp is undeployed?

Answer 1

The problem was self-inflicted (as most are). My data source was configured in my webapp's web.xml and I was referencing it via JNDI. I now create my data source as shown in the Spring reference doc (section 13.3.1) and the destroy method takes care of closing the data source and pool.

If I'd been required to stick with a JNDI data source I would have had to close out the data source in a class that implements ServletContextListener, in the contextDestroyed method.

Answer 2

This is a behaviour reported in Apache Tomcat bugzilla, Reference:

https://issues.apache.org/bugzilla/show_bug.cgi?id=25060

It has been corrected from Tomcat 7.0.11. Which version of Tomcat have you been using ?

If you use create the datasource as described in the Spring reference at"application level", you would a little overhead when it comes to administration tasks if you have a lot of applications and many servers.

Answer 3

I had the same problem and I could not use spring so I used a org.apache.tomcat.jdbc.pool.DataSourceProxy to close a Tomcat Datasource. This API provides you with functionality not yet implemented JDK DataSource interface.

DataSourceProxy myDataSource = (DataSourceProxy) myDataSource;
myDataSource.close();   

• Also using factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" and a ServletListener contextDestroyed method.