using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

日志：using the Connector/J connection property 'autoReconnect=true' to avoid this problem.  

\ 订阅

com.mysql.jdbc.CommunicationsException: The last packet successfully received from the server was58129 seconds ago.The last packet sent successfully to the server was 58129 seconds ago, which 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.

 

查了一下，原来是mysql超时设置的问题
如 果连接闲置8小时 (8小时内没有进行数据库操作), mysql就会自动断开连接, 要重启tomcat. 

 

 

解决办法：

 

 

    一种. 如果不用hibernate的话, 则在　connection url中加参数: autoReconnect=true

jdbc.url=jdbc:mysql://ipaddress:3306/database?autoReconnect=true&autoReconnectForPools=true

 

    二种。用hibernate的话, 加如下属性: 
        <property name="connection.autoReconnect">true</property>
        <property name="connection.autoReconnectForPools">true</property>
        <property name="connection.is-connection-validation-required">true</property>

 

    三。要是还用c3p0连接池: 
        <property name="hibernate.c3p0.acquire_increment">1</property> 
        <property name="hibernate.c3p0.idle_test_period">0</property> 
        <property name="hibernate.c3p0.timeout">0</property>
        <property name="hibernate.c3p0.validate">true</property>

 

 

　四。最不好的解决方案

 

使用Connector/J连接MySQL数据库，程序运行较长时间后就会报以下错误：

Communications link failure，The last packet successfully received from the server was *** millisecond ago.The last packet successfully sent to the server was ***  millisecond ago。

其中错误还会提示你修改wait_timeout或是使用Connector/J的autoReconnect属性避免该错误。

后来查了一些资料，才发现遇到这个问题的人还真不少，大部分都是使用连接池方式时才会出现这个问题，短连接应该很难出现这个问题。这个问题的原因：

MySQL服务器默认的“wait_timeout”是28800秒即8小时，意味着如果一个连接的空闲时间超过8个小时，MySQL将自动断开该 连接，而连接池却认为该连接还是有效的(因为并未校验连接的有效性)，当应用申请使用该连接时，就会导致上面的报错。

1.按照错误的提示，可以在JDBC URL中使用autoReconnect属性，实际测试时使用了autoReconnect=true& failOverReadOnly=false，不过并未起作用，使用的是5.1版本，可能真像网上所说的只对4之前的版本有效。

2.没办法，只能修改MySQL的参数了，wait_timeout最大为31536000即1年，在my.cnf中加入：

[mysqld]

wait_timeout=31536000

interactive_timeout=31536000

重启生效，需要同时修改这两个参数。

=============================================================================================================

MySQL数据库连接超时(wait_timeout)问题的处理

博客分类： 
• 积少成多

MySQL Linux Windows JDBC 活动 

    想必大家在用MySQL时都会遇到连接超时的问题，如下图所示： 
 
    就是这个异常(com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:Communications link failure Last packet sent to the server was X ms ago)，是由于MySQL服务在长时间不连接之后断开了，断开之后的首次请求会抛出这个异常。那么既然是连接超时的问题，就要去MySQL中探究一下连接时间是怎么控制的。打开MySQL的控制台，运行:show variables like ‘%timeout%’，查看和连接时间有关的MySQL系统变量，得到如下结果： 
 
    其中wait_timeout就是负责超时控制的变量，其时间为长度为28800s，就是8个小时，那么就是说MySQL的服务会在操作间隔8小时后断开，需要再次重连。也有用户在URL中使用jdbc.url=jdbc:mysql://localhost:3306/nd?autoReconnect=true来使得连接自动恢复，当然了，这是可以的，不过是MySQL4及其以下版本适用。MySQL5中已经无效了，必须调整系统变量来控制了。MySQL5手册中对两个变量有如下的说明： 
    interactive_timeout：服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。又见wait_timeout 
    wait_timeout:服务器关闭非交互连接之前等待活动的秒数。在线程启动时，根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值，取决于客户端类型(由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义)，又见interactive_timeout 
    如此看来，两个变量是共同控制的，那么都必须对他们进行修改了。继续深入这两个变量wait_timeout的取值范围是1-2147483(Windows)，1-31536000(linux)，interactive_time取值随wait_timeout变动，它们的默认值都是28800。 
    MySQL的系统变量由配置文件控制，当配置文件中不配置时，系统使用默认值，这个28800就是默认值。要修改就只能在配置文件里修改。Windows下在%MySQL HOME%/bin下有mysql.ini配置文件，打开后在如下位置添加两个变量，赋值。（这里修改为388000） 
    保存退出，重启mysql服务，一定是重启系统服务。便可看到修改结果： 
 
    Linux系统下的配置文件为/etc/my.cnf。需要多说一点的是：windows下的配置文件具体是哪个需要从windows系统服务中找到mysql，打开属性，看“可执行文件路径”里面的参数值，因为它可能是my.cnf而不是my.ini，这是由于安装时的设置，我们可能会忽略它。 
 
    至此，修改完成，那么连接超时的问题从数据库上就解决了。当然在编程时也可以使用连接池设置超时时间，配置相对简单。但修改数据库更为本质一些。 
    个人见解。希望对使用者有用。