MySQL+Hibernate下连接空闲8小时自动断开问题解决方案

MySQL+Hibernate下连接空闲8小时自动断开问题解决方案

前段时间刚完成一个家教网项目，数据库为MySQL5.0，持久层使用Hibernate 3.1，没有

使用额外的连接池，那么Hibernate会默认使用它自带的一个默认连接池，也就是

DriverManagerConnectionProvider。

先在本机上调试都毫无问题，于是部署到服务器上，也都没什么问题。由于这是新网站，

根本还没正式对外发布和宣传，所以头两天根本没人访问。等到第二天，我再次访问网站时，

问题就出现了，错误信息如下：

tException: nnectionException: could not

execute query

sException(:535)

sActionPerform(:433)

s(:236)

s(:1196)

(:414)

e(:690)

e(:803)

_jsp._jspService(index_:57)

e(:70)

e(:803)

e(:374)

eJspFile(:337)

e(:266)

e(:803)

er(:30)

nnectionException: could not execute query

t(:74)

t(:43)

(:2148)

noreQueryCache(:2029)

(:2024)

(:94)

(:1533)

(:283)

iclesUnder(:163)

e(:40)

sActionPerform(:431)

s(:236)

s(:1196)

(:414)

e(:690)

e(:803)

_jsp._jspService(index_:57)

e(:70)

e(:803)

e(:374)

eJspFile(:337)

e(:266)

e(:803)

er(:30)

onTransientConnectionException: No operations allowed

after connection tion was implicitly closed due to underlying exception/error:

** BEGIN NESTED EXCEPTION **

icationsException

MESSAGE: Communications link failure due to underlying exception:

** BEGIN NESTED EXCEPTION **

eption

STACKTRACE:

eption

at lly(:1963)

at ndReadPacket(:2375)

at rrorPacket(:2874)

at mmand(:1623)

at ryDirect(:1715)

at L(:3249)

at eInternal(:1268)

at eQuery(:1403)

at ultSet(:139)

at ultSet(:1669)

at y(:662)

at yAndInitializeNonLazyCollections(:224)

at (:2145)

at noreQueryCache(:2029)

at (:2024)

at (:94)

at (:1533)

at (:283)

at iclesUnder(:163)

at e(:40)

at sActionPerform(:431)

at s(:236)

at s(:1196)

at (:414)

at e(:690)

at e(:803)

at

alDoFilter(:290)

at er(:206)

at (:630)

at

sRequest(:436)

at ard(:374)

at d(:302)

at _jsp._jspService(index_:57)

at e(:70)

at e(:803)

at e(:374)

at eJspFile(:337)

at e(:266)

at e(:803)

at

alDoFilter(:290)

at er(:206)

at er(:30)

at

alDoFilter(:235)

at er(:206)

at (:233)

at (:175)

at (:128)

at (:102)

at (:109)

at e(:286)

at (:190)

at (:283)

at (:767)

at sConnection(:697)

at lSocket$(:889)

at Pool$(:690)

at (Unknown Source)

** END NESTED EXCEPTION **

Last packet sent to the server was 15 ms ago.

STACKTRACE:

icationsException: Communications link failure due to underlying

exception:

** BEGIN NESTED EXCEPTION **

eption

STACKTRACE:

eption

at lly(:1963)

at ndReadPacket(:2375)

at rrorPacket(:2874)

at mmand(:1623)

at ryDirect(:1715)

at L(:3249)

at eInternal(:1268)

at eQuery(:1403)

at ultSet(:139)

at ultSet(:1669)

at y(:662)

at yAndInitializeNonLazyCollections(:224)

at (:2145)

at noreQueryCache(:2029)

at (:2024)

at (:94)

at (:1533)

at (:283)

at iclesUnder(:163)

at e(:40)

at sActionPerform(:431)

at s(:236)

at s(:1196)

at (:414)

at e(:690)

at e(:803)

at

alDoFilter(:290)

at er(:206)

at (:630)

at

sRequest(:436)

at ard(:374)

at d(:302)

at _jsp._jspService(index_:57)

at e(:70)

at e(:803)

at e(:374)

at eJspFile(:337)

at e(:266)

at e(:803)

at

alDoFilter(:290)

at er(:206)

at er(:30)

at

alDoFilter(:235)

at er(:206)

at (:233)

at (:175)

at (:128)

at (:102)

at (:109)

at e(:286)

at (:190)

at (:283)

at (:767)

at sConnection(:697)

at lSocket$(:889)

at Pool$(:690)

at (Unknown Source)

** END NESTED EXCEPTION **

Last packet sent to the server was 15 ms ago.

at ndReadPacket(:2586)

at rrorPacket(:2874)

at mmand(:1623)

at ryDirect(:1715)

at L(:3249)

at eInternal(:1268)

at eQuery(:1403)

at ultSet(:139)

at ultSet(:1669)

at y(:662)

at yAndInitializeNonLazyCollections(:224)

at (:2145)

at noreQueryCache(:2029)

at (:2024)

at (:94)

at (:1533)

at (:283)

at iclesUnder(:163)

at e(:40)

at sActionPerform(:431)

at s(:236)

at s(:1196)

at (:414)

at e(:690)

at e(:803)

at

alDoFilter(:290)

at er(:206)

at (:630)

at

sRequest(:436)

at ard(:374)

at d(:302)

at _jsp._jspService(index_:57)

at e(:70)

at e(:803)

at e(:374)

at eJspFile(:337)

at e(:266)

at e(:803)

at

alDoFilter(:290)

at er(:206)

at er(:30)

at

alDoFilter(:235)

at er(:206)

at (:233)

at (:175)

at (:128)

at (:102)

at (:109)

at e(:286)

at (:190)

at (:283)

at (:767)

at sConnection(:697)

at lSocket$(:889)

at Pool$(:690)

at (Unknown Source)

** END NESTED EXCEPTION **

SQLException(:888)

losed(:1931)

eStatement(:4705)

eStatement(:4671)

paredStatement(:442)

paredStatement(:368)

eQueryStatement(:105)

eQueryStatement(:1561)

y(:661)

yAndInitializeNonLazyCollections(:224)

(:2145)

noreQueryCache(:2029)

(:2024)

(:94)

(:1533)

(:283)

iclesUnder(:163)

e(:40)

sActionPerform(:431)

s(:236)

s(:1196)

(:414)

e(:690)

e(:803)

_jsp._jspService(index_:57)

e(:70)

e(:803)

e(:374)

eJspFile(:337)

e(:266)

e(:803)

er(:30)

当时也搞不清楚为什么，但重启Tomcat后就一切回复正常了，但是又过了一天，问题再

次出现。仔细分析错误信息，问题肯定出在数据库连接部分，在网上查阅大量信息后，明确

了问题的原因：MySQL对所有连接的有效时间默认为28800秒，正好8小时，也就是说，如果

一个连接8小时没有请求和操作，就会自动断开；但是对于Hibernate来说，它的连接池并不

知道它所管理的连接中是否有被MySQL断开的。如果一个程序要使用数据库连接，而Hibernte

的连接池分配一个已经被MySQL断开了的给程序使用，那么便会出现错误。

为了证实确实是这个错误，我在本机上做了如下测试：首先启动Tomcat，网站能够正常

打开；然后修改系统时间，往后调1天；然后再打开网站，同样的问题果然出现！MySQL +

Hibernate架构相当普遍，所以这个问题也相当普遍，若读者也有这样的项目，建议做一下同

样的测试，看看是否存在此问题！

问题找到了，怎么解决呢？

思路1：增大MySQL的连接有效时间；

思路2：从程序自身出发，修改连接池的相关参数。

显然，思路1是不可行的，一方面这个思路不可能保证这个问题绝对的解决，如果无访问

时间够长，还是大于MySQL的连接有效时间，问题同样会发生；另一方面，一般情况下，

我们都是将程序部署在别人服务器上，我们不可能去修改MySQL配置。那么只能从思路2入

手了。

经查资料发现，Hibernate支持如下的连接池：

DriverManagerConnectionProvider：代表由Hibernate提供的默认的数据库连接池

C3P0ConnectionProvider：代表C3P0连接池

ProxoolConnectionProvider：代表Proxool连接池

DBCPConnectionProvider：代表DBCP连接池

DatasourceConnectionProvider：代表在受管理环境中由容器提供的数据源

其中，默认连接池并不支持在分配一个连接时，测试其有效与否的功能，而C3P0、Proxool、

DBCP都提供了这样的功能，正好可以解决上述问题。综合考虑各个连接池的效率、稳定性、

易用性，决定换用Proxool，它确实在各方面表现优良，方便配置。

下面就看看如何配置Proxool：

1、Hibernate配置文件：

name="er_class">lConnectionProvider

mysql

false

ialect

...

其中各属性含义如下：

er_class：指明使用Proxool连接池

：指明Proxool配置文件所在位置，这里与Hibernate的配置文件在同一

目录下

_alias：指明要使用的中定义的proxool别名。

2、Proxool配置文件（）：

mysql

jdbc:mysql://localhost/yourDatebase?useUnicode=true&characterEncoding=UTF-8

90000

20

3

20

3

true

true

SELECT CURRENT_USER

3、下载和安装Proxool的包文件

下载地址：/

下载后并解压后，将其中lib文件夹下的jar文件拷贝到你站点的WEB-INF/lib下

自此，Proxool配置成功。重新启动Tomcat，再次做上述测试，问题解决。

此外，如果要使用C3P0或DHCP，可以参考以下资料：

/lip8654/archive/2008/02/26/

/blog/182146

/blog/90793