com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after co

异常信息

org.hibernate.exception.JDBCConnectionException: could not execute query at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java: 74 ) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java: 43 ) ....... Caused by: com.mysql.jdbc.exceptions.MySQLNonTransientConnectionException: No operations allowed after connection closed.Connection was implicitly closed due to underlying exception/error: ** BEGIN NESTED EXCEPTION ** com.mysql.jdbc.CommunicationsException MESSAGE: Communications link failure due to underlying exception: ** BEGIN NESTED EXCEPTION ** java.net.SocketException MESSAGE: Broken pipe STACKTRACE: java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) ...... ** END NESTED EXCEPTION **

缘由分析

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

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

解决方案

解决的方法有3种：

1. 增长 wait_timeout 的时间。
2. 减小 Connection pools 中 connection 的 lifetime。
3. 测试 Connection pools 中 connection 的有效性。

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

DBCP 增长如下配置信息:

validationQuery = "select 1"



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"

C3P0 增长如下配置信息:

//获取connnection时测试是否有效
testConnectionOnCheckin = true



//自动测试的table名称
automaticTestTable=C3P0TestTable



//set to something much less than wait_timeout, prevents connections from going stale
idleConnectionTestPeriod = 18000



//set to something slightly less than wait_timeout, preventing 'stale' connections from being handed out
maxIdleTime = 25000



//if you can take the performance 'hit', set to "true"
testConnectionOnCheckout = true

simple jdbc dataSource 增长如下配置信息:

Pool.PingQuery = select 1



Pool.PingEnabled = true



Pool.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 等于多少才是合适的值呢？ 因此并不推荐这个解决办法。)

 

原文地址：http://www.cnblogs.com/hemingwang0902/archive/2012/03/15/2397620.html

 

附件：

三大链接池的参数说明 

 

1. Apache-DBCP

? BasicDataSource 相关的参数说明

• dataSource: 要链接的 datasource (一般咱们不会定义在 server.xml)
• defaultAutoCommit: 对于事务是否 autoCommit, 默认值为 true
• defaultReadOnly: 对于数据库是否只能读取, 默认值为 false
• driverClassName:链接数据库所用的 JDBC Driver Class,
• maxActive: 能够从对象池中取出的对象最大个数，为0则表示没有限制，默认为8
• maxIdle: 最大等待链接中的数量,设 0 为没有限制 （对象池中对象最大个数）
• minIdle：对象池中对象最小个数
• maxWait: 最大等待秒数, 单位为 ms, 超过期间会丟出错误信息
• password: 登录数据库所用的密码
• url: 链接数据库的 URL
• username: 登录数据库所用的账号
• validationQuery: 验证链接是否成功, SQL SELECT 指令至少要返回一行
• removeAbandoned: 是否自我中断, 默认是 false
• removeAbandonedTimeout: 几秒后会自我中断, removeAbandoned 必须为 true
• logAbandoned: 是否记录中断事件, 默认为 false
• minEvictableIdleTimeMillis：大于0 ，进行链接空闲时间判断，或为0，对空闲的链接不进行验证；默认30分钟
• timeBetweenEvictionRunsMillis：失效检查线程运行时间间隔，若是小于等于0，不会启动检查线程，默认-1
• testOnBorrow：取得对象时是否进行验证，检查对象是否有效，默认为false
• testOnReturn：返回对象时是否进行验证，检查对象是否有效，默认为false
• testWhileIdle：空闲时是否进行验证，检查对象是否有效，默认为false

? 在使用DBCP的时候，若是使用默认值，则数据库链接由于某种缘由断掉后，再从链接池中取得链接又不进行验证，这时取得的链接实际上就会是无效的数据库链接。所以为了防止得到的数据库链接失效，在使用的时候最好保证：

• username: 登录数据库所用的账号
• validationQuery：SELECT COUNT(*) FROM DUAL
• testOnBorrow、testOnReturn、testWhileIdle：最好都设为true
• minEvictableIdleTimeMillis：大于0 ，进行链接空闲时间判断，或为0，对空闲的链接不进行验证
• timeBetweenEvictionRunsMillis：失效检查线程运行时间间隔，若是小于等于0，不会启动检查线程

? PS:在构造GenericObjectPool [BasicDataSource在其createDataSource () 方法中也会使用GenericObjectPool] 时，会生成一个内嵌类Evictor，实现自Runnable接口。若是timeBetweenEvictionRunsMillis大于0，每过timeBetweenEvictionRunsMillis毫秒Evictor会调用evict()方法，检查对象的闲置时间是否大于 minEvictableIdleTimeMillis毫秒（_minEvictableIdleTimeMillis小于等于0时则忽略，默认为30分钟），是则销毁此对象，不然就激活并校验对象，而后调用ensureMinIdle方法检查确保池中对象个数不小于_minIdle。在调用returnObject方法把对象放回对象池，首先检查该对象是否有效，而后调用PoolableObjectFactory 的passivateObject方法使对象处于非活动状态。再检查对象池中对象个数是否小于maxIdle，是则能够把此对象放回对象池，不然销毁此对象

? 上述特性的可设置性已在代码中验证，具体性能是否能实现有待实际验证

2. C3P0

? C3P0的官方example中使用的数据源为ComboPooledDataSource，网上一篇文章详细介绍了C3P0链接池配置中各项含义[这些配置项的含义在下载解压c3p0的压缩包以后目录的doc\index.html中的Configuration部分也有详细的介绍，这里偷下懒:P]，现摘录以下：

3


30


1000


false


Test


">false


100


e">


null


nsactions">false


">60


3


60


15


100


on">


3


root


password





select id from test where id=1


300


">false


true


root


eProxies">false

con_test
    30000
    ">30
    10
    30
    25
    10
    0
    
    


    200
    
      300
    
   

? 上述特性的可设置性已在代码中验证，具体性能是否能实现有待实际验证

? 从配置项的内容来看，C3P0和DBCP都有比较详细的有关链接检测保证的配置，咱们能够看到C3P0能够控制数据源内加载的PreparedStatements数量，而且能够设置帮助线程的数量来提高JDBC操做的速度，这些是DBCP未提供的；另外从网络上的评价来看，DBCP出现Bug的频率要大于C3P0，不过这一点有待于咱们本身实际的检测。

3. Proxool

? Proxool的使用和dbcp以及c3p0稍有不一样，咱们须要而且只须要在使用基本的java.sql.DriverManager以前加载org.logicalcobwebs.proxool.ProxoolDriver驱动类,而且按照proxool定义的url格式 ["proxool." + alias + ":" + driverClass + ":" + driverUrl ，其中alias是为链接池自定义的别名] 来得到connection；具体的能够参看proxool doc下的UserGuide，或本文所附的示例代码。下面对链接池的特性配置做详细说明 [这个是本身翻译的，不必定准确，有问题时请参看doc下的Properties ~]。

n fatal-sql-exception

以逗号隔开的异常列表，当设置了此项以后，每当出现SQLException时都将与列表中异常项做比较，若是匹配则认为出现fatal异常，这将致使connection被丢弃，而且不论出现任何状况该异常将被重抛一次以通知用户发生的状况。默认值为null

n fatal-sql-exception-wrapper-class

若是配置了fatal-sql-exception，则默认的操做是丢 弃引发SQLException的缘由而只是抛出原始异常。使用fatal-sql-exception-wrapper-class这个特性能够将 SQLException包装到继承SQLException或RunTimeException的任何异常类里。Proxool提供了两个类供使用 FatalSQLException和FatalRunTimeException；使用这两个类的话就将该选项设置为 'org.logicalcobwebs.proxool.FatalSQLException'或者 'org.logicalcobwebs.proxool.FatalRuntimeException'。默认值为null

n house-keeping-sleep-time

proxool自动侦察各个链接状态的时间间隔(毫秒),侦察到空闲的链接就立刻回收,超时的销毁，默认值为30秒

n house-keeping-test-sql

若是侦察线程发现闲置链接，则会使用这个SQL语句来对这些链接进行检查；这项设置的语句应该可以被很快的执行，例如查询当前时间 [info.setProperty("proxool.house-keeping-test-sql", "select CURRENT_DATE");] 。若是不设置则该选项被忽略

n injectable-connection-interface、injectable-statement-interface、injectable-prepared-statement-interface、injectable-callable-statement-interface

n jmx

若是此项设为true，则链接池将被以名称"Proxool:type=Pool, name="注册为JMS Server的MBean。默认值为false

n jmx-agent-id

当且仅当jmx选项设为true时使用，为以逗号分隔的链接持注册到的JMS代理名称列表；若是不设置则全部注册的JMX Server都将被使用

n maximum-active-time

线程最大存活时间，超过此时间的线程将被守护线程kill掉，默认值为5分钟

n maximum-connection-count

到数据库的最大链接数，超过了这个链接，再有请求时，就排在队列中等候，最大的等待请求数由simultaneous-build-throttle决定；默认值为15

n maximum-connection-lifetime

链接最大存活时间，毫秒为单位，默认值为4小时

n minimum-connection-count

不论是否被使用都保持开放的最小链接数，默认值为5

n overload-without-refusal-lifetime

用来判断链接池状态，若是在此选项设置时间内（毫秒为单位）拒绝了链接，则认为过负载。默认值为60秒

n prototype-count

最少保持的空闲链接数，注意与minimum-connection-count区分。默认值为0

n simultaneous-build-throttle

最大的等待请求数，默认值为10

n test-before-use

若是设为true则connection在使用前将以house-keeping-test-sql设置的语句测试，若是测试不经过则该connection被丢弃并会从新分配一个connection。默认为false

n test-after-use

若是设为true则connection在关闭（放回链接池）前将以house-keeping-test-sql设置的语句测试，若是测试不经过connection将被丢弃。默认值为false

? 与其它链接池特性的设置方法不一样，Proxool不提供相应的set方法，全部特性都要以诸如info.setProperty("proxool.jmx", "false");方式设定

? 上述特性的可设置性已在代码中验证，具体性能是否能实现有待实际验证

 

原文地址：http://zhangsha1251.blog.163.com/blog/static/62624053201182111921783/