MySQL中wait_timeout的坑

今天遇到了一个问题，一个项目，放到服务器（tomcat）下面的跑，但第二天，总是报错，项目还不能跑

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 1 milliseconds ago.  The last packet sent successfully to the server was 1 milliseconds ago.
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
    at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1127)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3715)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3604)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4155)
    at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2615)
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2776)
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2838)
    at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2082)
    at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1307)
    at com.alibaba.druid.filter.FilterChainImpl.preparedStatement_execute(FilterChainImpl.java:2931)
    at com.alibaba.druid.filter.FilterEventAdapter.preparedStatement_execute(FilterEventAdapter.java:440)
    at com.alibaba.druid.filter.FilterChainImpl.preparedStatement_execute(FilterChainImpl.java:2929)
    at com.alibaba.druid.proxy.jdbc.PreparedStatementProxyImpl.execute(PreparedStatementProxyImpl.java:131)
    at com.alibaba.druid.pool.DruidPooledPreparedStatement.execute(DruidPooledPreparedStatement.java:493)
    at org.apache.ibatis.executor.statement.PreparedStatementHandler.query(PreparedStatementHandler.java:59)
    at org.apache.ibatis.executor.statement.RoutingStatementHandler.query(RoutingStatementHandler.java:73)
    at org.apache.ibatis.executor.SimpleExecutor.doQuery(SimpleExecutor.java:60)
    at org.apache.ibatis.executor.BaseExecutor.queryFromDatabase(BaseExecutor.java:267)
    at org.apache.ibatis.executor.BaseExecutor.query(BaseExecutor.java:137)
    at org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:96)
    at org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:77)
    at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:108)
    at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:102)
    at org.activiti.engine.impl.db.DbSqlSession.selectListWithRawParameter(DbSqlSession.java:443)
    at org.activiti.engine.impl.db.DbSqlSession.selectList(DbSqlSession.java:434)
.......

发现这个问题是MySQL的坑：

　　wait_timeout的作用是，设置非交互连接（就是指那些连接池方式、非客户端方式连接的）的超时时间，默认是28800，就是8小时，超过这个时间，mysql服务器会主动切断那些已经连接的，但是状态是sleep的连接。而我们后端程序是运行在windows下的，所以安装的myodbc，并使用ado方式连接的，也就是连接池方式，这种方式的坏处是，当服务器端去连接mysql的时候，连接池里的连接已经被mysql主动断开，这时取回的连接就是null，再加上程序里对此没有做判断的话，接下来的对数据库的一系列的操作都会出现问题。

解决方案：

《1》增加 MySQL 的 wait_timeout 属性的值 （不推荐）

　　修改mysql安装目录下的配置文件 my.ini文件，这两个参数的默认值是8小时(60*60*8=28800)

wait_timeout=1814400 
interactive_timeout=1814400 

《2》减少连接池内连接的生存周期

　　减少连接池内连接的生存周期，使之小于上一项中所设置的wait_timeout 的值。修改 c3p0 的配置文件，在 Spring 的配置文件中设置：

<bean id="dataSource"  class="com.mchange.v2.c3p0.ComboPooledDataSource">      
    <property name="maxIdleTime"value="1800"/>  
    <!--other properties -->  
 </bean>

《3》定期使用连接池内的连接

　　定期使用连接池内的连接，使得它们不会因为闲置超时而被 MySQL 断开。修改 c3p0 的配置文件,在 Spring 的配置文件中设置：

<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">  
    <property name="preferredTestQuery" value="SELECT 1"/>  
    <property name="idleConnectionTestPeriod" value="18000"/>  
    <property name="testConnectionOnCheckout" value="true"/>  
</bean>