c3p0数据源的使用初步及Mysql8小时问题解决 c3p0号称是java界最好的数据池。 c3p0的配置方式分为三种，分别是 1.setters一个个地设置各个配置项 2.类路径下提供一个c3p0.properties文件 3.类路径下提供一个c3p0-config.xml文件 我们主要说下c3p0-config.xml配
c3p0数据源的使用初步及Mysql8小时问题解决c3p0号称是java界最好的数据池。
c3p0的配置方式分为三种，分别是
1.setters一个个地设置各个配置项
2.类路径下提供一个c3p0.properties文件
3.类路径下提供一个c3p0-config.xml文件
我们主要说下c3p0-config.xml配置：
//默认池配置
//命名池配置
可见c3p0可以配置在一个应用中使用多个池。换言之可以使用多个数据库。
使用：
//使用默认池：
private static ComboPooledDataSource ds = new ComboPooledDataSource();
//使用命名池
private static ComboPooledDataSource ds = new ComboPooledDataSource("myApp");
基本配置项的介绍：
1.基本配置
acquireIncrement
default : 3
连接池在无空闲连接可用时一次性创建的新数据库连接数
initialPoolSize
default : 3
连接池初始化时创建的连接数
maxPoolSize
default : 15
连接池中拥有的最大连接数，如果获得新连接时会使连接总数超过这个值则不会再获取新连接，而是等待
其他连接释放，所以这个值有可能会设计地很大
maxIdleTime
default : 0 单位 s
连接的最大空闲时间，如果超过这个时间，某个数据库连接还没有被使用，则会断开掉这个连接
如果为0，则永远不会断开连接
minPoolSize
default : 3
连接池保持的最小连接数，后面的maxIdleTimeExcessConnections跟这个配合使用来减轻连接池的负载
2.管理连接池的大小和连接的生存时间
maxConnectionAge
default : 0 单位 s
配置连接的生存时间，超过这个时间的连接将由连接池自动断开丢弃掉。当然正在使用的连接不会马上断开，而是等待
它close再断开。配置为0的时候则不会对连接的生存时间进行限制。
maxIdleTimeExcessConnections
default : 0 单位 s
这个配置主要是为了减轻连接池的负载，比如连接池中连接数因为某次数据访问高峰导致创建了很多数据连接
但是后面的时间段需要的数据库连接数很少，则此时连接池完全没有必要维护那么多的连接，所以有必要将
断开丢弃掉一些连接来减轻负载，必须小于maxIdleTime。配置不为0，则会将连接池中的连接数量保持到minPoolSize。
为0则不处理。
3.配置连接测试：因为连接池中的数据库连接很有可能是维持数小时的连接，很有可能因为数据库服务器的问题，网络问题等导致实际连接已经无效，但是连接池里面的连接还是有效的，如果此时获得连接肯定会发生异常，所以有必要通过测试连接来确认连接的有效性。
下面的前三项用来配置如何对连接进行测试，后三项配置对连接进行测试的时机。
automaticTestTable
default : null
用来配置测试连接的一种方式。配置一个表名，连接池根据这个表名创建一个空表，
并且用自己的测试sql语句在这个空表上测试数据库连接
这个表只能由c3p0来使用，用户不能操作，同时用户配置的preferredTestQuery 将会被忽略。
preferredTestQuery
default : null
用来配置测试连接的另一种方式。与上面的automaticTestTable二者只能选一。
如果要用它测试连接，千万不要设为null，否则测试过程会很耗时，同时要保证sql语句中的表在数据库中一定存在。
connectionTesterClassName
default : com.mchange.v2.c3p0.impl.DefaultConnectionTester
连接池用来支持automaticTestTable和preferredTestQuery测试的类，必须是全类名，就像默认的那样，
可以通过实现UnifiedConnectionTester接口或者继承AbstractConnectionTester来定制自己的测试方法
idleConnectionTestPeriod
default : 0
用来配置测试空闲连接的间隔时间。测试方式还是上面的两种之一，可以用来解决MySQL8小时断开连接的问题。因为它
保证连接池会每隔一定时间对空闲连接进行一次测试，从而保证有效的空闲连接能每隔一定时间访问一次数据库，将于MySQL
8小时无会话的状态打破。为0则不测试。
testConnectionOnCheckin
default : false
如果为true，则在close的时候测试连接的有效性。为了提高测试性能，可以与idleConnectionTestPeriod搭配使用，
配置preferredTestQuery或automaticTestTable也可以加快测试速度。
testConnectionOnCheckout
default : false
性能消耗大。如果为true，在每次getConnection的时候都会测试，为了提高性能，
可以与idleConnectionTestPeriod搭配使用，
配置preferredTestQuery或automaticTestTable也可以加快测试速度。
4.配置PreparedStatement缓存
maxStatements
default : 0
连接池为数据源缓存的PreparedStatement的总数。由于PreparedStatement属于单个Connection,所以
这个数量应该根据应用中平均连接数乘以每个连接的平均PreparedStatement来计算。为0的时候不缓存，
同时maxStatementsPerConnection的配置无效。
maxStatementsPerConnection
default : 0
连接池为数据源单个Connection缓存的PreparedStatement数，这个配置比maxStatements更有意义，因为
它缓存的服务对象是单个数据连接，如果设置的好，肯定是可以提高性能的。为0的时候不缓存。
注意当数据池不再使用时需要调用close()方法手动关闭它配置举例：
我的c3p0配置实例：C3P0Test 60 60 10 100 10 100 30000
解决MYSQL 8小时问题
Mysql服务器默认的“wait_timeout”是8小时，也就是说一个connection空闲超过8个小时，Mysql将自动断开该 connection。这就是问题的所在，在C3P0 pools中的connections如果空闲超过8小时，Mysql将其断开，而C3P0并不知道该connection已经失效，如果这时有 Client请求connection，C3P0将该失效的Connection提供给Client，将会造成上面的异常。
解决的方法有3种：
增加wait_timeout的时间。
减少Connection pools中connection的lifetime。
测试Connection pools中connection的有效性。
C3P0增加以下配置信息:
//自动测试的table名称
automaticTestTable=C3P0TestTable
//set to something much less than wait_timeout, prevents connections from going stale。每个小时测试一次
idleConnectionTestPeriod = 3600
//set to something slightly less than wait_timeout, preventing 'stale' connections from being handed out最大空闲时间为2个小时
maxIdleTime = 7200
//获取connnection时测试是否有效
testConnectionOnCheckin = true
整体说明：
补充一点，与c3p0配置无关，但是对于tomcat中配置DBCP很重要。
对于tomcat中的DBCP，也需要解决Mysql 8小时问题，所以需要这样：
//set to 'SELECT 1'
validationQuery = "SELECT 1"
//set to 'true'
testWhileIdle = "true"
//some positive integer
timeBetweenEvictionRunsMillis = 3600000
//set to something smaller than 'wait_timeout'
minEvictableIdleTimeMillis = 18000000
//if you don't mind a hit for every getConnection(), set to "true"
testOnBorrow = "true"
参考：http://my.oschina.net/lyzg/blog/55133
http://www.blogjava.net/Alpha/archive/2009/03/29/262789.html
