C3P0参数的使用（3）

Configuring Statement Pooling
C3P0实现了透明的PreparedStatement池，它是根据JDBC规范定义的。在一些环境下，statement池能很大地提升应用的性能。在另一些环境下，statement池的花销也会轻微损害性能。当statement被准备时，statement池是否以及怎样提高性能，取决于怎样解析，计划，和数据库查询的优化。数据库以及JDBC驱动差异巨大。基于你的应用使用和不用statement池，取决于是否能提升性能。
maxStatements是控制statement池的JDBC标准参数。maxStatement定义了数据源缓冲的PreparedStatements总数。当它达到这个限制时，池将会销毁最近最少使用的PreparedStatement。这听起来简单，但是确切地是一个陌生的方法，因为缓冲的statement概念上属于不同的连接；他们不是全局的资源。理解maxStatements的大小，对于maxStatements，它没有搅动缓冲的statement，你需要考虑你应用中频繁使用的PreparedStatements数量。maxStatementsPerConnection是非标准的配置参数。它定义了每个被缓冲的连接中多少statement是被允许使用的。你能设置它比你频繁使用的PreparedStatements数目多，避免搅动。
如果这些参数都大于0，statement池将会被启动。如果两个参数都大于0，限制将会是被启用。如果仅有一个大于0，statement池将会是被启用，但是仅仅一个限制被启用。

Configuring Recovery From Database Outages
C3P0数据源是被设计（并且默认被配置）来从临时数据库损坏中恢复，例如发生在数据库重启或者网络连接的短期损失。
当C3P0数据源试图取得连接并且失败时，它将会重试直到acquireRetryAttempts设定的次数；并且每次的重试的间隔是acquireRetryDelay。如果所有的重试都失败，任一等待数据库连接的客户端都会看到异常，说明不可以取得连接。注意在一轮重试都失败之前客户端不会看到任意的异常。如果acquireRetryAttempts设置为0，C3P0将会无限期地试图取得新的连接，并且调用getConnection()也许会无限期地阻塞，等待一个成功的确认。
一旦一轮都重试失败，有两种可能的策略。默认情况下，C3P0数据源将仍会是活跃的，并且将会重试取得连接。如果你设置breakAfterAcquireFailure为true，在一轮的连接失败后，数据源将会考虑自身被破坏，将来的请求将会立即失败。
注意如果数据库发生重启，池也许包含了先前取得的胆识现在陈旧的连接。默认请款下，这些陈旧的连接将被侦测到并且延迟清除，当应用试图使用它们，并且会看到异常。设置maxIdleTime或者maxConnectionAge能帮助加速被破坏连接的替换。如果你希望避免整体应用异常，你必须采用连接测试策略，该策略可能先于它们传送给客户端之前侦测到陈旧的连接。即使使用活跃的连接测试（testConnectionsOnCheckout被设置为true，或者testConnectionsOnCheckin以及一个简短的idleConnectionTestPeriod），在数据库重启的时候，你的应用也许会看到偶然的异常。例如，在数据库连接被check out之后，如果数据库被重启。