mysql wait_timeout=_MySQL中wait_timeout的坑

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

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

The last packet successfully received from the server was1 milliseconds ago. The last packet sent successfully to the server was 1milliseconds 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 的配置文件中设置：

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

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