C3P0参数的使用（4）

Managing Connection Lifecycles with Connection Customizer
在连接取得后，应用逐渐希望使用标准的可复用的方法立即创建连接。例如，这包括了字符编码，或者日期和时间相关的行为，使用供应商指定的API或者非标准的SQL statement执行。偶然地，重载标准连接的默认值是有用的，例如transactionIsolation，holdability或者readOnly。C3P0提供了你可以实现“钩子”接口，它给你机会在连接从数据库check out之后调整或者跟踪连接。
安装ConnectionCustomizer，仅仅需要实现接口，使你的类可以访问C3P0的类加载器。
ConnectionCustomizers是被要求为不可变的类，使用public修饰的无参数构造函数。它们不应该存储任何状态。对于很少的应用，它们希望去追踪不同数据库的行为，lifecycle方法接收指定数据源的“identityToken”，它对于PoolDataSource是唯一的。

Configuring Unresolved Transaction Handling
进入池的连接不能有任何未处理的事务工作与它们相关。如果用户已经设置了autoCommit为false，并且C3P0不能保证没有等待事务在工作，C3P0必须是提交或者回滚。默认情况下当用户调用close()时C3P0回滚未解决的事务。
如果你希望C3P0允许未解决的事务提交，设置autoCommitOnClose到true。如果你希望C3P0留下事务管理给你，并且既不回滚也不提交，你也许设置forceIgnoreUnresolvedTransactions为true。设置forceIgnoreUnresolvedTransactions这个行为并不被鼓励，因为如果客户端不关注先于close()提交或者回滚自身，或者一直不设置连接的自动提交，奇异的不重复行为以及数据库查找能发生。

Configuring to Debug and Workaround Broken Client Applications
有时客户端应用是松散的，关于关闭它们取出的所有的连接。最后，连接池增长到maxPoolSize，然后耗光所有的连接，由于这些坏的客户端。
解决问题正确的方式是修复客户端应用。C3P0能帮助你调试，通过让你知道连接是在哪儿检出的，偶然地没有检出。在很少的、不幸的情况下，客户端应用的开发是闭合的，并且尽管它是有Bug的，但是你不能修复它。C3P0能帮助你解决被破坏的应用，阻止它耗尽连接池。
unreturnedConnectionTimeout 对连接是被检出的时间定义了限制（秒级）。如果设置为非零值，不返回的，检出的连接超出了这个限制的话将会被销毁，然后在连接池中被替换。
明显的，你必须将这个参数设置为足够大的值让操作有时间去完成。你很少能使用这个参数解决不可靠的客户端应用，这些应用关闭连接失败。
除了设置unreturnedConnectionTimeout，你设置debugUnreturnedConnectionStackTraces为true，然后stack trace将会被捕获在每次连接是被check-out时。无论何时未返回的连接超时，stack trace将会是被打印。debugUnreturnedConnectionStackTraces是被紧紧用来调试，捕获stack trace能减慢连接check-out。