连接mysql异常处理：MySQLNonTransientConnectionException: No operations allowed after connection closed

异常信息（部分）：

2014-11-26 12:01:47,815 [http-6888-6] WARN  com.mchange.v2.c3p0.impl.NewPooledConnection - [c3p0] A PooledConnection that has already signalled a Connection error is still in use!

2014-11-26 12:01:47,829 [http-6888-6] WARN  com.mchange.v2.c3p0.impl.NewPooledConnection - [c3p0] Another error has occurred [ com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed. ] which will not be reported to listeners! com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.mysql.jdbc.Util.handleNewInstance(Util.java:408) at com.mysql.jdbc.Util.getInstance(Util.java:383) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1023) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:997) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:983) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:928) at com.mysql.jdbc.ConnectionImpl.throwConnectionClosedException(ConnectionImpl.java:1323) at com.mysql.jdbc.ConnectionImpl.checkClosed(ConnectionImpl.java:1315) at com.mysql.jdbc.ConnectionImpl.rollback(ConnectionImpl.java:5057)

at com.mchange.v2.c3p0.impl.NewProxyConnection.rollback(NewProxyConnection.java:855)

原因分析

查看了Mysql的文档，以及Connector/J的文档以及在线说明发现，出现这种异常的原因是：

　　Mysql服务器默认的“wait_timeout”是8小时，也就是说一个connection空闲超过8个小时，Mysql将自动断开该connection。这就是问题的所在，在C3P0 pools中的connections如果空闲超过8小时，Mysql将其断开，而C3P0并不知道该connection已经失效，如果这时有Client请求connection，C3P0将该失效的Connection提供给Client，将会造成上面的异常。

配置解决方案：

myapp.properties信息

db-driver=com.mysql.jdbc.Driver db-url=jdbc:mysql://localhost:3306/mydb?useUnicode=true&characterEncoding=UTF-8 db-username=mytest db-password=123456

core.js信息

var ioc = { config : { type : "org.nutz.ioc.impl.PropertiesProxy", fields : { paths : ["/conf/myapp.properties"] } }, dataSource : { type :"com.mchange.v2.c3p0.ComboPooledDataSource", events : { depose :"close" }, fields : { driverClass : {java :"$config.get('db-driver')"}, jdbcUrl             : {java :"$config.get('db-url')"}, user        : {java :"$config.get('db-username')"}, password        : {java :"$config.get('db-password')"}, minPoolSize     : 5, initialPoolSize : 10, maxPoolSize     : 100, testConnectionOnCheckin : true, automaticTestTable : "C3P0TestTable",      －－    这些是针对MySQLNonTransientConnectionException新加的属性 idleConnectionTestPeriod : 18000, maxIdleTime : 300, maxStatements : 0,          －－防止c3p0 APPARENT DEADLOCK的问题 numHelperThreads : 5    －－防止c3p0 APPARENT DEADLOCK的问题 } }, // Dao dao : { type :'com.test.my.TestDao', args : [ {refer :"dataSource"}] } }; com.test.my.TestDao 类，该类直接继承了NutDao ，如果非必要，那么type里面可以直接写NutDao 。 public class TestDao extends NutDao { public TestDao () { super(); // TODO Auto-generated constructor stub } public TestDao (DataSource dataSource, SqlManager sqlManager) { super(dataSource, sqlManager); // TODO Auto-generated constructor stub } public TestDao (DataSource dataSource) { super(dataSource); // TODO Auto-generated constructor stub }

//下面是一些自己的方法 }

解决方案

解决的方法有3种：

增加 wait_timeout 的时间。减少 Connection pools 中 connection 的 lifetime。测试 Connection pools 中 connection 的有效性。

当然最好的办法是同时综合使用上述3种方法，下面就 DBCP、C3P0 和 simple jdbc dataSource 分别做一说明，假设 wait_timeout 为默认的8小时

DBCP 增加以下配置信息:

validationQuery = "select 1"testWhileIdle = "true"//some positive integertimeBetweenEvictionRunsMillis = 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"

C3P0 增加以下配置信息:

//获取connnection时测试是否有效testConnectionOnCheckin = true//自动测试的table名称automaticTestTable=C3P0TestTable//set to something much less than wait_timeout, prevents connections from going staleidleConnectionTestPeriod = 18000//set to something slightly less than wait_timeout, preventing 'stale' connections from being handed outmaxIdleTime = 25000//if you can take the performance 'hit', set to "true"testConnectionOnCheckout = true

simple jdbc dataSource 增加以下配置信息:

Pool.PingQuery = select 1Pool.PingEnabled = truePool.PingConnectionsOlderThan = 0//对于空闲的连接一个小时检查一次Pool.PingConnectionsNotUsedFor = 3600000

其他方案（不推荐）

　　对于 MySQL5 之前的版本，如 Mysql4.x，只需要修改连接池配置中的 URL，添加一个参数：autoReconnect=true(如jdbc:mysql://hostaddress:3306/schemaname?autoReconnect=true)，如果是 MySQL5 及以后的版本，则需要修改 my.cnf(或者my.ini) 文件，在 [mysqld] 后面添加上：

wait_timeout = n interactive-timeout = n

其中 n 为服务器关闭交互式连接前等待活动的秒数。可是就部署而言每次修改 my.ini 比较麻烦，而且 n 等于多少才是合适的值呢？ 所以并不推荐这个解决办法。)

c3p0详细配置 官方文档 :  http://www.mchange.com/projects/c3p0/index.html <c3p0-config> <default-config> <!--当连接池中的连接耗尽的时候c3p0一次同时获取的连接数。Default: 3 --> <property name="acquireIncrement">3</property> <!--定义在从数据库获取新连接失败后重复尝试的次数。Default: 30 --> <property name="acquireRetryAttempts">30</property> <!--两次连接中间隔时间，单位毫秒。Default: 1000 --> <property name="acquireRetryDelay">1000</property> <!--连接关闭时默认将所有未提交的操作回滚。Default: false --> <property name="autoCommitOnClose">false</property> <!--c3p0将建一张名为Test的空表，并使用其自带的查询语句进行测试。如果定义了这个参数那么 属性preferredTestQuery将被忽略。你不能在这张Test表上进行任何操作，它将只供c3p0测试 使用。Default: null--> <property name="automaticTestTable">Test</property> <!--获取连接失败将会引起所有等待连接池来获取连接的线程抛出异常。但是数据源仍有效 保留，并在下次调用getConnection()的时候继续尝试获取连接。如果设为true，那么在尝试 获取连接失败后该数据源将申明已断开并永久关闭。Default: false--> <property name="breakAfterAcquireFailure ">false</property> <!--当连接池用完时客户端调用getConnection()后等待获取新连接的时间，超时后将抛出 SQLException,如设为0则无限期等待。单位毫秒。Default: 0 --> <property name="checkoutTimeout">100</property> <!--通过实现ConnectionTester或QueryConnectionTester的类来 测试连接。类名需制定全路径。 Default: com.mchange.v2.c3p0.impl.DefaultConnectionTester--> <property name="connectionTesterClassNam e"></property> <!--指定c3p0 libraries的路径，如果（通常都是这样）在本地即可获得那么无需设置，默认null即可 Default: null--> <property name="factoryClassLocation">null</property> <!--Strongly disrecommended. Setting this to true may lead to subtle and bizarre bugs. （文档原文）作者强烈建议不使用的一个属性--> <property name="forceIgnoreUnresolvedTra nsactions">false</property> <!--每60秒检查所有连接池中的空闲连接。Default: 0 --> <property name="idleConnectionTestPeriod ">60</property> <!--初始化时获取三个连接，取值应在minPoolSize与maxPoolSize之间。Default: 3 --> <property name="initialPoolSize">3</property> <!--最大空闲时间,60秒内未使用则连接被丢弃。若为0则永不丢弃。Default: 0 --> <property name="maxIdleTime">60</property> <!--连接池中保留的最大连接数。Default: 15 --> <property name="maxPoolSize">15</property> <!--JDBC的标准参数，用以控制数据源内加载的PreparedStatements数量。但由于预缓存的statements 属于单个connection而不是整个连接池。所以设置这个参数需要考虑到多方面的因素。 如果maxStatements与maxStatementsPerConnection均为0，则缓存被关闭。Default: 0--> <property name="maxStatements">100</property> <!--maxStatementsPerConnection定义了连接池内单个连接所拥有的最大缓存statements数。Default: 0 --> <property name="maxStatementsPerConnecti on"></property> <!--c3p0是异步操作的，缓慢的JDBC操作通过帮助进程完成。扩展这些操作可以有效的提升性能 通过多线程实现多个操作同时被执行。Default: 3--> <property name="numHelperThreads">3</property> <!--当用户调用getConnection()时使root用户成为去获取连接的用户。主要用于连接池连接非c3p0 的数据源时。Default: null--> <property name="overrideDefaultUser">root</property> <!--与overrideDefaultUser参数对应使用的一个参数。Default: null--> <property name="overrideDefaultPassword">password</property> <!--密码。Default: null--> <property name="password"></property> <!--定义所有连接测试都执行的测试语句。在使用连接测试的情况下这个一显著提高测试速度。注意： 测试的表必须在初始数据源的时候就存在。Default: null--> <property name="preferredTestQuery">select id from test where id=1</property> <!--用户修改系统配置参数执行前最多等待300秒。Default: 300 --> <property name="propertyCycle">300</property> <!--因性能消耗大请只在需要的时候使用它。如果设为true那么在每个connection提交的 时候都将校验其有效性。建议使用idleConnectionTestPeriod或automaticTestTable 等方法来提升连接测试的性能。Default: false --> <property name="testConnectionOnCheckout ">false</property> <!--如果设为true那么在取得连接的同时将校验连接的有效性。Default: false --> <property name="testConnectionOnCheckin">true</property> <!--用户名。Default: null--> <property name="user">root</property> <!--早期的c3p0版本对JDBC接口采用动态反射代理。在早期版本用途广泛的情况下这个参数 允许用户恢复到动态反射代理以解决不稳定的故障。最新的非反射代理更快并且已经开始 广泛的被使用，所以这个参数未必有用。现在原先的动态反射与新的非反射代理同时受到 支持，但今后可能的版本可能不支持动态反射代理。Default: false--> <property name="usesTraditionalReflectiv eProxies">false</property> <property name="automaticTestTable">con_test</property> <property name="checkoutTimeout">30000</property> <property name="idleConnectionTestPeriod ">30</property> <property name="initialPoolSize">10</property> <property name="maxIdleTime">30</property> <property name="maxPoolSize">25</property> <property name="minPoolSize">10</property> <property name="maxStatements">0</property> <user-overrides user="swaldman"> </user-overrides> </default-config> <named-config name="dumbTestConfig"> <property name="maxStatements">200</property> <user-overrides user="poop"> <property name="maxStatements">300</property> </user-overrides> </named-config> </c3p0-config>

mysql wait_timeout和interactive_timeout总结

(1) interactive_timeout: 参数含义：服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。 参数默认值：28800秒（8小时） (2) wait_timeout: 参数含义：服务器关闭非交互连接之前等待活动的秒数。 在线程启动时，根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值，取决于客户端类型(由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义)。

参数默认值：28800秒（8小时）

问题1：这里为什么要同时设置interactive_timeout,wait_timeout的设置才会生效？ 答：    不设置interactive_timeout,wait_timeout也会生效。 问题2：interactive的值如果设置的和wait_timeout不同，为什么Interactive_timeout会覆盖wait_timeout? 答：在交互模式下(CLIENT_INTERACTIVE),interactive_timeout才生效，非交互模式下，不生效。 问题3：在进行MySQL优化时，因为interactive_timeout决定的是交互连接的时间长短，而wait_timeout决定的是非交互连接的时间长短。如果在进行连接配置时mysql_real_connect()最后一个参数client_flag不设置为CLIENT_INTERACTIVE，是不是interactive_timeout的值不会覆盖wait_timeout? 答：可以做实验试试。 问题4：为了减少长连接的数量，在设置优化时是不是可以将interactive_timeout的值设置的大些，而wait_timeout的值设置的小些？但是问题2的描述好像又不允许这样。。。 答：如2所述，在交互模式下，interactive_timeout取代wait_timeout。这样，如果有的客户端是交互模式方式连接mysql server。那么客户端的timeout受制于interactive_timeout。如果有的客户端是非交互模式，长连接mysql server。那么客户端的timeout受制于wait_timeout。(是否是交互模式的连接，由客户端决定)

 

参考：

http://www.blogjava.net/Alpha/archive/2009/03/29/262789.html

http://blog.csdn.net/bedweather/article/details/6743951

http://www.cnblogs.com/hemingwang0902/archive/2012/03/15/2397620.html http://blog.sina.com.cn/s/blog_53b58e7c010197bj.html