亲亲宝宝

java.lang.Exception: DEBUG — CLOSE BY CLIENT STACK TRACE
at com.mchange.v2.c3p0.impl.NewPooledConnection.close (NewPooledConnection.java:491)
at com.mchange.v2.c3p0.impl.NewPooledConnection.close (NewPooledConnection.java:191)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$ 1PooledConnectionResourcePoolManager.destroyResour ce(C3P0PooledConnectionPool.java:470)

错误不会影响C3PO的使用，最简单的方法时提高日志输出级别，就看不到了。

这个错误很可能是automaticTestTable配置引起的，使用<property name=”preferredTestQuery” value=”select * from dual” /> ，这个属性就可以既能检测连接，还不用建立垃圾表，当然这个是在oracle中，dual是自带的虚拟表吗，sqlserver和mysql的from及以后就可以省掉了。

补充：在http://hi.baidu.com/xhr8334/blog/item/cf15d1a6deb235fc9052ee9b.html看到一个见解

我看到那个DEBUG,我说，是调试信息，修改一下LOG4J的等级就行了。

这个群友很不解的问，既然成功了，干嘛还要丢异常出来？

这里就不得不说到两个商业开发的原则问题了。

第一，对上家传入数据严加过滤，对传出给下家的数据仔细检查。

第二，合理使用异常。

第一点其实很简单的。也就是模块化开发的一个思想问题。对自己的行为负责。前端返回的数据究竟是什么，需要进行校验。不合格的剔除或者是修正。合格的处理完后，在传出之前也要加以校验，是否合格。

具体到这个问题里，就是来自Spring关于数据源的那个配置文件。

<bean destroy-method=”close”>

//略去数据源相关信息的配置

</bean>

这个配置文件里，有两个信息是很管用的。一个是class，一个是destroy-method。简单点说，一个是数据源的实现类，一个是析构方 法。Spring在读取这个配置文件以后，需要根据这些信息来实例化一些类，然后内部再根据中间的那些配置信息来实际构造数据源。比如username啥 的。

可是来了个问题。不能保证这里的ComboPooledDataSource数据源一定是可用的，也不能保证close方法一定能关闭连接，对 吧？Spring本身不能检查这个类是否真实有效，毫无Bug。实际上呢，也检查不了。同样的，close方法是否有效，也需要进行检查。这就是我刚才说 的，对上家数据的严加检查。

那好吧，怎么检查呢？最简洁的方法莫过于实际构造一下，连接池，获取数据库连接，执行一个测试语句，然后关闭连接。如果一切都成功，那就OK。关于 那个测试语句，配置过WebSphere数据源的同学们还记得不？有个SQL语句会默认的写在数据源配置里，是 ” SELECT 1 FROM TABLE “。嗯，对的，这个就是测试语句。

这一套流程能走得通，走的顺，那么就可以在自己能力范围内说这个数据源和连接池是能用的，对吧？

这里补充一个知识。java.sql.Connection，这玩意不是class，是interface。

声明是：public interface Connection extends Wrapper 。

任何一个JDBC数据库连接的实现类都应该实现这个接口的全部方法。比如，close。API里的描述是，立即释放此 Connection 对象的数据库和 JDBC 资源，而不是等待它们被自动释放。

熟悉Java的同学们应该记得一点，在规范里有个要求，就是接口的实现类必须实现接口的所有方法。但是呢，这句话还有个意思，那就是，你可以在实现所有方法之外，再写几个方法。没人会管你。

啊哈，那就有疑问了。虽然API规定了close是关闭连接释放资源的。但这只是你接口的一厢情愿。也许人家实现厂家觉得close方法不够帅，要 改成closeConnection。那。。。Spring总不好傻傻的去死扣close方法来关闭连接吧？虽然这方法必须实现，但是可没说一定要有内容 啊。如果是空方法呢？

所以有了destroy-method这个配置项的出现。Spring说，不碍的，您老人家看哪个爽，告诉我就行。

现在测试完了。一切都成功了。