原文地址:http://blog.csdn.net/dxswzj/article/details/42778031
问题原因:
其实上面的提示中已经给出了一部分的简要说明,简单来说就是: 程序启动时,在跟DB首次交互时,获得了相应的DB Connection资源,从而进行正常的DB读写操作。但是在下次进行DB读写时(我的定时任务本身设置的时间间隔是24小时),应用程序认为这个连接是可以正常使用的(程序执行过一次之后没有退出,这个连接从来并没有被释放掉),但实际上,这个连接已经坏掉了,因为Mysql本身已经把这个连接标记为timeout了。于是,应用程序“傻乎乎”的在这个已经坏掉的数据通道上发起对DB的读写请求,但是Mysql已经对这些请求不买账了。。。
为啥呀,mysql到底认为这个连接空闲多长时间算过期啊?
这个可以通过查看mysql的配置文件,看看是否有对这个时间做过特殊的配置,我的场景下在64位linux服务器上部署的mysql服务器,这个配置文件在:在/etc/my.cnf
如果你打开这个文件,发现并没有如下这行配置:
- wait_timeout=xxx (这里xxx是数据,单位为秒)
说明你并没有对这个timeout做过特殊配置,通常Mysql默认的配置是8小时。你也可以在登陆进入mysql之后,通过如下命令确认一下:
- show global variables like ‘wait_timeout’;
结合上面我的程序的配置(24小时执行一次),上面的问题就好解释了:24小时之后程序再次对DB进行读写操作时,Mysql单方已经认为之前connection已经timeout了(停止活动了8小时以上就认为过期了)。
如何解决:
1.1 错误信息:
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 20,820,001 milliseconds ago. The last packet sent successfully to the server was 20,820,002 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
at sun.reflect.GeneratedConstructorAccessor29.newInstance(Unknown Source) ~[na:na]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.7.0_51]
at java.lang.reflect.Constructor.newInstance(Constructor.java:526) ~[na:1.7.0_51]
at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.29.jar:na]
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1129) ~[mysql-connector-java-5.1.29.jar:na]
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3988) ~[mysql-connector-java-5.1.29.jar:na]
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2598) ~[mysql-connector-java-5.1.29.jar:na]
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2778) ~[mysql-connector-java-5.1.29.jar:na]
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2828) ~[mysql-connector-java-5.1.29.jar:na]
at com.mysql.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:5372) ~[mysql-connector-java-5.1.29.jar:na]
at com.mchange.v2.c3p0.impl.NewProxyConnection.setAutoCommit(NewProxyConnection.java:881) ~[c3p0-0.9.1.1.jar:0.9.1.1]
at org.quartz.impl.jdbcjobstore.AttributeRestoringConnectionInvocationHandler.setAutoCommit(AttributeRestoringConnectionInvocationHandler.java:98) ~[quartz-2.2.1.jar:na]
1.2 解决方法
– 如果使用的是JDBC,在JDBC URL上添加?autoReconnect=true
,如:
jdbc:mysql://10.10.10.10:3306/mydb?autoReconnect=true
– 如果是在Spring中使用DBCP连接池,在定义datasource增加属性validationQuery
和testOnBorrow
,如:
<bean id="vrsRankDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="${jdbc.driverClassName}" />
<property name="url" value="${countNew.jdbc.url}" />
<property name="username" value="${countNew.jdbc.user}" />
<property name="password" value="${countNew.jdbc.pwd}" />
<property name="validationQuery" value="SELECT 1" />
<property name="testOnBorrow" value="true"/>
</bean>
– 如果是在Spring中使用c3p0连接池,则在定义datasource的时候,添加属性testConnectionOnCheckin
和testConnectionOnCheckout
,如:
<bean name="cacheCloudDB" class="com.mchange.v2.c3p0.ComboPooledDataSource">
<property name="driverClass" value="${jdbc.driver}"/>
<property name="jdbcUrl" value="${cache.url}"/>
<property name="user" value="${cache.user}"/>
<property name="password" value="${cache.password}"/>
<property name="initialPoolSize" value="10"/>
<property name="maxPoolSize" value="${cache.maxPoolSize}"/>
<property name="testConnectionOnCheckin" value="false"/>
<property name="testConnectionOnCheckout" value="true"/>
<property name="preferredTestQuery" value="SELECT 1"/>
</bean>