I have been battling to get database connections stable in an application running on tomcat 6.0.26 with hibernate persistence.

For testing purposes, I set mysql wait_timeout and interactive_timeout to 32s. context.xml is as follows:
<Resource name="jdbc/SomeDB" auth="Container" type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000"
username="${mysql.username}" password="${mysql.password}" driverClassName="com.mysql.jdbc.Driver"
removeAbandoned="true" removeAbandonedTimeout="30" logAbandoned="true"
validationQuery="SELECT 1" testOnBorrow="true" testOnReturn="true"
timeBetweenEvictionRunsMillis="30000" minEvictableIdleTimeMillis="28000" testWhileIdle="true"
url="jdbc:mysql://${mysql.host}:3306/somedb"/>

I only recently added the lines from removeAbandoned to the evictor setup recently, still fails

persistence.xml:
<persistence-unit name="someDatabase" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<non-jta-data-source>java:comp/env/jdbc/SomeDB</jta-data-source>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
<property name="hibernate.hbm2ddl.auto" value="validate"/>
<property name="hibernate.show_sql" value="true"/>
<property name="hibernate.cache.provider_class" value="org.hibernate.cache.HashtableCacheProvider"/>

<property name="hibernate.c3p0.provider_class" value="org.hibernate.connection.C3P0ConnectionProvider" />
<property name="hibernate.c3p0.acquire_increment" value="5" />
<property name="hibernate.c3p0.idle_test_period" value="30" />
<property name="hibernate.c3p0.timeout" value="30" />
<property name="hibernate.c3p0.max_size" value="100" />
<property name="hibernate.c3p0.min_size" value="5" />
<property name="hibernate.c3p0.max_statements" value="0" />
<property name="hibernate.c3p0.preferredTestQuery" value="select 1;" />
</properties>

I added c3p0 after initial connection errors, thinking that this might resolve the issues, but it doesn't. When monitoring the database activity (show processlist in mysql), a single connection is made to the table when I access the webapp, and is removed after 32s - there is no keepalive. When I access the application after the connection has been removed, an exception is thrown:

SEVERE: Exception sending request destroyed lifecycle event to listener instance of class org.jboss.weld.environment.servlet.Listener
org.hibernate.exception.GenericJDBCException: Cannot release connection
at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:126)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:114)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:52)
...
Caused by: java.sql.SQLException: Already closed.
at org.apache.tomcat.dbcp.dbcp.PoolableConnection.close(PoolableConnection.java:114)
at org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:191)
at org.hibernate.connection.DatasourceConnectionProvider.closeConnection(DatasourceConnectionProvider.java:97)
at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:474)
... 27 more

Hibernate versions:
'org.hibernate:hibernate-commons-annotations:3.1.0.GA',
'org.hibernate:hibernate-entitymanager:3.4.0.GA',
'org.hibernate:hibernate-annotations:3.4.0.GA',
'org.hibernate:hibernate-c3p0:3.3.2.GA',
'javax.persistence:persistence-api:1.0',

There is also a <property name="hibernate.connection.pool_size" value="10" /> configured in persistence.xml

the problem is with dbcp. have tested by using tomcat jdbc-pool and c3p0 to manage the connection pool for the jndi datasource, and the connections work as expected.

<sebersole> the problem is that dbcp is verifying the connection to some extent
the problem is that dbcp *is* verifying the connection to some extent
connection.close(); connection.close(); connection.close(); is a valid sequence of calls
dbcp is not letting that happen
its why close() is supposed to just no-op on subsequent calls

other connection pooling libraries allow subsequent close() calls.