在单元测试测试环境下主要参数两个错误信息:
[b]1.[/b]java.lang.Exception: DEBUG STACK TRACE for PoolBackedDataSource.close().
这是一个异常信息,在com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.close(AbstractPoolBackedDataSource.java:417)
方法中可以看到
public synchronized void close()
{
resetPoolManager();
is_closed = true;
C3P0Registry.markClosed(this);
if (Debug.DEBUG && Debug.TRACE == Debug.TRACE_MAX && logger.isLoggable(MLevel.FINEST))
{
logger.log(MLevel.FINEST,
this.getClass().getName() + '@' + Integer.toHexString( System.identityHashCode( this ) ) +
" has been closed. ",
new Exception("DEBUG STACK TRACE for PoolBackedDataSource.close()."));
}
}
if (Debug.DEBUG && Debug.TRACE == Debug.TRACE_MAX && logger.isLoggable(MLevel.FINEST))
这句判断中,只要log的debug级别打开,就可以确定会抛出这个Exception(奇怪的设计)。所以这个异常想要不出现,除了改log级别,没想到其他方式。
[b]2.[/b]DEBUG -- CLOSE BY CLIENT STACK TRACE
[junit] java.lang.Exception: DEBUG -- CLOSE BY CLIENT STACK TRACE
[junit] at com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:566)
[junit] at com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:234)
[junit] at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.destroyResource(C3P0PooledConnectionPool.java:470)
[junit] at com.mchange.v2.resourcepool.BasicResourcePool$1DestroyResourceTask.run(BasicResourcePool.java:964)
[junit] at com.mchange.v2.resourcepool.BasicResourcePool.destroyResource(BasicResourcePool.java:989)
[junit] at com.mchange.v2.resourcepool.BasicResourcePool.access$100(BasicResourcePool.java:32)
[junit] at com.mchange.v2.resourcepool.BasicResourcePool$5.run(BasicResourcePool.java:1174)
c3p0的配置如下
<!-- 数据源配置 -->
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
<property name="driverClass" value="${connection.driver_class}" />
<property name="jdbcUrl" value="${jdbc.connection.url}" />
<property name="idleConnectionTestPeriod"
value="${jdbc.pool.c3p0.idle_connection_test_period}" />
<property name="preferredTestQuery" value="${jdbc.pool.c3p0.preferred_test_query}" />
<property name="maxIdleTime" value="${jdbc.pool.c3p0.max_idle_time}" />
<property name="properties">
<props>
<prop key="user">${jdbc.connection.username}</prop>
<prop key="password">${jdbc.connection.password}</prop>
<prop key="c3p0.acquire_increment">${jdbc.pool.c3p0.acquire_increment}</prop>
<prop key="c3p0.max_size">${jdbc.pool.c3p0.max_size}</prop>
<prop key="c3p0.min_size">${jdbc.pool.c3p0.min_size}</prop>
</props>
</property>
</bean>
这里原因主要和<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
这的destroy-method方法有关系。
Spring在读取这个配置文件以后,需要根据这些信息来实例化一些类,然后内部再根据中间的那些配置信息来实际构造数据源。
那么自然就不能保证这里的ComboPooledDataSource数据源一定是可用的,也不能保证close方法一定能关闭连接,对吧?Spring本身不能检查这个类是否真实有效,毫无Bug。实际上呢,也检查不了。同样的,close方法是否有效,也需要进行检查。
java.sql.Connection
public interface Connection extends Wrapper
任何一个JDBC数据库连接的实现类都应该实现这个接口的全部方法。比如,close。API里的描述是,立即释放此 Connection 对象的数据库和 JDBC 资源,而不是等待它们被自动释放。
虽然API规定了close是关闭连接释放资源的。但这只是你接口的一厢情愿。也许人家实现厂家觉得close方法不够帅,要改成closeConnection。那。。。Spring总不好傻傻的去死扣close方法来关闭连接吧?虽然这方法必须实现,但是可没说一定要有内容啊。如果是空方法呢?所以有了destroy-method这个配置项的出现。
总结:
当不能确定destory-method的情况下,把该项删除,由程序自主选择关闭方法,这样Debug就不会报错了.
摘自http://csumissu.iteye.com/blog/1079576
[b]1.[/b]java.lang.Exception: DEBUG STACK TRACE for PoolBackedDataSource.close().
这是一个异常信息,在com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.close(AbstractPoolBackedDataSource.java:417)
方法中可以看到
public synchronized void close()
{
resetPoolManager();
is_closed = true;
C3P0Registry.markClosed(this);
if (Debug.DEBUG && Debug.TRACE == Debug.TRACE_MAX && logger.isLoggable(MLevel.FINEST))
{
logger.log(MLevel.FINEST,
this.getClass().getName() + '@' + Integer.toHexString( System.identityHashCode( this ) ) +
" has been closed. ",
new Exception("DEBUG STACK TRACE for PoolBackedDataSource.close()."));
}
}
if (Debug.DEBUG && Debug.TRACE == Debug.TRACE_MAX && logger.isLoggable(MLevel.FINEST))
这句判断中,只要log的debug级别打开,就可以确定会抛出这个Exception(奇怪的设计)。所以这个异常想要不出现,除了改log级别,没想到其他方式。
[b]2.[/b]DEBUG -- CLOSE BY CLIENT STACK TRACE
[junit] java.lang.Exception: DEBUG -- CLOSE BY CLIENT STACK TRACE
[junit] at com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:566)
[junit] at com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:234)
[junit] at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.destroyResource(C3P0PooledConnectionPool.java:470)
[junit] at com.mchange.v2.resourcepool.BasicResourcePool$1DestroyResourceTask.run(BasicResourcePool.java:964)
[junit] at com.mchange.v2.resourcepool.BasicResourcePool.destroyResource(BasicResourcePool.java:989)
[junit] at com.mchange.v2.resourcepool.BasicResourcePool.access$100(BasicResourcePool.java:32)
[junit] at com.mchange.v2.resourcepool.BasicResourcePool$5.run(BasicResourcePool.java:1174)
c3p0的配置如下
<!-- 数据源配置 -->
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
<property name="driverClass" value="${connection.driver_class}" />
<property name="jdbcUrl" value="${jdbc.connection.url}" />
<property name="idleConnectionTestPeriod"
value="${jdbc.pool.c3p0.idle_connection_test_period}" />
<property name="preferredTestQuery" value="${jdbc.pool.c3p0.preferred_test_query}" />
<property name="maxIdleTime" value="${jdbc.pool.c3p0.max_idle_time}" />
<property name="properties">
<props>
<prop key="user">${jdbc.connection.username}</prop>
<prop key="password">${jdbc.connection.password}</prop>
<prop key="c3p0.acquire_increment">${jdbc.pool.c3p0.acquire_increment}</prop>
<prop key="c3p0.max_size">${jdbc.pool.c3p0.max_size}</prop>
<prop key="c3p0.min_size">${jdbc.pool.c3p0.min_size}</prop>
</props>
</property>
</bean>
这里原因主要和<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
这的destroy-method方法有关系。
Spring在读取这个配置文件以后,需要根据这些信息来实例化一些类,然后内部再根据中间的那些配置信息来实际构造数据源。
那么自然就不能保证这里的ComboPooledDataSource数据源一定是可用的,也不能保证close方法一定能关闭连接,对吧?Spring本身不能检查这个类是否真实有效,毫无Bug。实际上呢,也检查不了。同样的,close方法是否有效,也需要进行检查。
java.sql.Connection
public interface Connection extends Wrapper
任何一个JDBC数据库连接的实现类都应该实现这个接口的全部方法。比如,close。API里的描述是,立即释放此 Connection 对象的数据库和 JDBC 资源,而不是等待它们被自动释放。
虽然API规定了close是关闭连接释放资源的。但这只是你接口的一厢情愿。也许人家实现厂家觉得close方法不够帅,要改成closeConnection。那。。。Spring总不好傻傻的去死扣close方法来关闭连接吧?虽然这方法必须实现,但是可没说一定要有内容啊。如果是空方法呢?所以有了destroy-method这个配置项的出现。
总结:
当不能确定destory-method的情况下,把该项删除,由程序自主选择关闭方法,这样Debug就不会报错了.
摘自http://csumissu.iteye.com/blog/1079576