MYSQL BUG #5020及解决方法
Connection was closed due to the following exception:
** BEGIN NESTED EXCEPTION **
java.sql.SQLException
MESSAGE: Communication link failure: java.net.SocketException, underlying cause: Software caused connection abort: recv failed
** BEGIN NESTED EXCEPTION **
java.net.SocketException
MESSAGE: Software caused connection abort: recv failed
STACKTRACE:
java.net.SocketException: Software caused connection abort: recv failed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:222)
at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1385)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1532)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1923)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1163)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1272)
at com.mysql.jdbc.Connection.execSQL(Connection.java:2236)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1555)
at net.sf.hibernate.impl.BatcherImpl.getResultSet(BatcherImpl.java:89)
at net.sf.hibernate.loader.Loader.getResultSet(Loader.java:880)
at net.sf.hibernate.loader.Loader.doQuery(Loader.java:273)
at net.sf.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:138)
at net.sf.hibernate.loader.Loader.doList(Loader.java:1063)
at net.sf.hibernate.loader.Loader.list(Loader.java:1054)
at net.sf.hibernate.hql.QueryTranslator.list(QueryTranslator.java:854)
at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1554)
at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1531)
at net.sf.hibernate.impl.SessionImpl.delete(SessionImpl.java:1678)
at net.sf.hibernate.impl.SessionImpl.delete(SessionImpl.java:1664)
出错原因：
我们的系统一天24小时运行，但在夜晚的时候是没有人连接的，因此Socket连接就超时了。早上尝试做任何事情（比如：登录）都将以失败告终，除非我们关闭连接或者重新建立连接。到3.0.11后才会发生这种情况。
现在我们使用的MYSQL版本号为4.016，问题一样。
专家建议：
[Mark Matthews],翻译如下：
注意：我不赞成Autoreconnect功能，在以后的发行版本中，它最终会被移除。在这种特殊情况下， 它不起作用的原因是：在3.0.11以后，autoreconnect的方法变得更加安全了并且和阿utoCommit状态有关联，这样的话就能使当前‘in-flight’事务失败（如果你在失败后，再次试图连接事务，就会重新被连接）。请查看相关解释文档，文档的修复故障中包括如何正确实用这个属性。无论在哪种情况下， 如果TCP/IP在没有连接的情况下并且还不会冒着数据库被瘫痪的危险，是没有百分之百的方式使得JDBC驱动器被自动重连接的，这也是为何要移除Autoreconnect功能的原因。不管网络发生什么情况， JDBC 都不会说明这个连接是否处于连接状态。JDBC driver 客户端负责处理网络故障，只有应用程序本身（实际上是应用程序的开发者）知道如何正确应对事务失败的情况。在服务器上过期的‘Wait—timeout’基本上是服务器给与的强制性网络故障。你通过把‘Wait—timeout’设置的高点儿就可以改正它，尽管如此，作为一个开发者，你的代码应该包含相关的异常处理并采取适当的恢复措施，不要都把它们传到调用堆中。
连接错误总是有一个SQL状态‘08’。如果你发现它的话，你可以再连接一次并重试事务（如果是适当的话）
不管什么原因，如果这样不起作用的话，配置你的连接池来测试是否处于连接状态并且那些长时间闲置连接（所有的连接池都能这样做，但是它们的配置取决于池子）。
作者说明：在MYSQL4.1以后的版本当中，没有“wait_timeout”变量，由interactiveClient代替
参考资料：http://dev.mysql.com/doc/connector/j/en/cj-configuration-properties.html
[Kirk Wylie]:翻译如下：
如果有一个事务在运行的话，就能得到一个特别简单的例子：
—如果连接在autoCommit模式下,autoReconnect是安全的。
—如果连接不在autoCommit模式下，但是没有打开的事务，autoReconnect是安全的。（因为连接可能在池在里面）
—如果连接不在autoCommit模式下，有打开的事务，这样就会抛出异常。
这样会解决你不在autoRecom\nnect模式下的忧虑并且会保留应用程序的功能性。
尽管如此，在它改变的时候，在改变日志中没有任何记录说明发生了改变，这点令我很烦。由于这种改变很可能破坏我的应用程序，这种变化因该添加到CHANGE文件中。
