MyBatis连接MySQL出错:No operations allowed after connection closed

时间:2022-10-04 09:27:21


异常信息

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 增加以下配置信息:

MyBatis连接MySQL出错:No operations allowed after connection closed
 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"
MyBatis连接MySQL出错:No operations allowed after connection closed

C3P0 增加以下配置信息:

MyBatis连接MySQL出错:No operations allowed after connection closed
 //获取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
MyBatis连接MySQL出错:No operations allowed after connection closed

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

MyBatis连接MySQL出错:No operations allowed after connection closed
 Pool.PingQuery = select 1

Pool.PingEnabled = true

Pool.PingConnectionsOlderThan = 0

//对于空闲的连接一个小时检查一次

Pool.PingConnectionsNotUsedFor = 3600000
MyBatis连接MySQL出错:No operations allowed after connection closed

其他方案(不推荐)

  对于 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: 登陆数据库所用的帐号
  • validationQuerySELECT COUNT(*) FROM DUAL
  • testOnBorrowtestOnReturntestWhileIdle:最好都设为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
    
   

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

? 从配置项的内容来看,C3P0DBCP都有比较详细的有关连接检测保证的配置,我们可以看到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-interfaceinjectable-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/