DBCP & tomcat leave connections upon redeploy.

[blockzter]

We have an app which defines JNDI resources inside spring [dataAccess.xml] as

org.springframework.jndi.JndiObjectFactoryBean

and uses both JDBC template and StoreProcedure data access. In addition, we define data sources [db] inside our tomcat configuration file [as found in ~/tomcat/conf/Catalina/localhost/xxx.xml] using DBCP:

	. . .
	<ResourceParams name="jdbc/xxxDS">
		<parameter>
			<name>factory</name>
			<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
		</parameter>
		<parameter>
			<name>driverClassName</name>
			<value>oracle.jdbc.driver.OracleDriver</value>
		</parameter>
	. . .

The issue we run into is if we redeploy to tomcat by copying the WAR file into the webapps directory, the old connections to the database are not detroyed. I know that if I define the datasource within spring, I can specify the destroy method, however this is not acceptable since we've several environments in which to run this app.


Springframework 1.1.5
DBCP 1.2.1
Tomcat 5.0.28

Any ideas on how to solve this issue? Since we use

org.springframework.web.servlet.DispatcherServlet

I was thinking of subclassing it and having it invoke the dbcp's destroy....of course there's getting hold of the dbcp object....

Thanks.

[Rod Johnson]

I know that if I define the datasource within spring, I can specify the destroy method, however this is not acceptable since we've several environments in which to run this app.

I don't understand this. Do you mean that it must come from JNDI for some reason (e.g. you'll deploy it in WebLogic as well and don't want to change the app)?

I would refactor the XML definitions to pull out the datasource and transaction manager so that you can easily deploy to a different environment and switch between a JNDI and local datasource easily.

The alternative you're suggesting to get around the Tomcat problem sounds more like hacking to me...

[blockzter]

We deploy to tomcat, however we have dev, qa, and production environments each with different database connection information. By using JNDI resources we extract any environment specific information from the WAR file. The definitions for these JNDI resources is held with in the specific environment's container [ala ~/tomcat/conf/Catalina/localhost/xxx.xml].

This xxx.xml file simply defines the actual resources while the spring config contains references to these resources.


Hmm, this makes me think....
If we define the database connections w/i spring using variable substitution. Would I be able to define the values for these vars in the container's environment...

I'll have to experiment....

thanks.

[Rod Johnson]

If we define the database connections w/i spring using variable substitution. Would I be able to define the values for these vars in the container's environment...

Look at the PetStore and PetClinic sample applications. These pull out database connection details into properties files.

[blockzter]

Since we were defining our datasources as JNDI via JndiObjectFactoryBean,
I subclassed it, added a cleanupPool method, and of course, updated the spring config files to use the new class as well as destroy-method. Unfortuately, it only deals with DBCP...I explicitly check for it. It probably could be cleaned up to be more generic....perhaps w/ some reflection to make it generic.

The subclass follows:

public class DBCleanupJndiObjectFactoryBean extends JndiObjectFactoryBean {
	private static final Log LOG = LogFactory.getLog(DBCleanupJndiObjectFactoryBean.class);

	public DBCleanupJndiObjectFactoryBean() {
		super();
		// TODO Auto-generated constructor stub
	}

	/**
	 * Close down the connection pool iff BasicDataSource.
	 */
	public void cleanupPool() {
		Object o = this.getObject();
		LOG.debug("OBJ: " + o);
		
		if (o instanceof BasicDataSource) {
			try {
				LOG.debug("Closing connection pool to " + ((BasicDataSource)o).getUrl());
				((BasicDataSource)o).close();
			} catch(SQLException e){
				LOG.error("Failed to close connection pool: ", e);
			}
		} else {
			LOG.warn("Unhandled type!");
		}
	}
}