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.