最近在將本地的JavaWeb項目部署到服務器上之后遇到的一個奇怪問題
- 在部署完成后，網站當時可以正常工作，但是第二天訪問網站的時候卻會遇到一個500 Server Error。
Tomcat 的日志中關鍵信息如下:
05-May-2017 05:15:27.682 SEVERE [http-nio-8080-exec-5] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [Login] in context with path [] threw exception
org.hibernate.exception.JDBCConnectionException: could not execute query
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 83,827,560 milliseconds ago. The last packet sent successfully to the server was 83,827,560 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.
Caused by: java.net.SocketException: Broken pipe (Write failed)
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3721)
... 41 more
從日志中可以看出是MySQL數據庫出現了異常
The last packet successfully received from the server was 83,827,560 milliseconds ago. The last packet sent successfully to the server was 83,827,560 milliseconds ago. is longer than the server configured value of 'wait_timeout'
最后一個數據包在 83827560 ms 之前被成功接收，最后一個數據包在83827560 ms 之前被成功發送。比服務的配置參數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.
你應考慮在程序中進行數據庫操作之前檢驗數據庫連接的有效性或者將數據庫的autoConnect屬性設置為true來避免這個問題。
在google上搜索之后，發現問題出在如果超過這個wait_timeout時間(默認是8小時)對數據庫沒有任何操作，那么MySQL會自動關閉數據庫連接以節省資源。而我的網站對數據庫進行操作的時候卻并未判斷數據庫連接是否斷開，因此在管道（pipe）的這一端請求數據而另一端卻被關閉的情況下，就會拋出這個Broken pipe異常。
這里就有一個疑問: 日志上說最后一個數據包是在 83827560ms 之前被成功接收和發送的，這個時間換算過來大概就是139分鐘，也就是2小時多一點，明顯沒有超過wait_timeout的值。但是數據庫連接自動斷開的問題確實是在第二天發生了，也就是在一個晚上沒有對數據庫進行操作(顯然超過了8小時)的情況下發生的這個問題。
這個疑問我暫時還沒有找到答案，希望有知道的大神賜教。
不過既然找到了這個問題，那么我們就很容易考慮到如下的幾個解決方案:
- 在主線程中定時發送一個
SELECT操作來確保數據庫一直保持連接狀態。 - 延長數據庫的wait_timeout時間。
- 按照日志中給出的解決方案在程序中進行數據庫操作之前檢驗數據庫連接的有效性。
- 按照日志中給出的解決方案將MySQL數據庫的
autoConnect屬性設置為true。
接下來一一分析這幾個解決方案是否可行
方法一
- 通過定時的
SELECT操作來保持數據庫連接的有效性
首先看一下我的Hibernate配置文件
<hibernate-configuration>
<session-factory>
<!-- Database connection settings -->
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="connection.url">jdbc:mysql://localhost:3306/DatabaseName</property>
<property name="connection.characterEncoding">utf-8</property>
<property name="connection.username">root</property>
<property name="connection.password">password</property>
<!-- SQL dialect -->
<property name="dialect">org.hibernate.dialect.MySQLDialect</property>
<property name="show_sql">true</property>
<!--mapping files-->
......
</session-factory>
</hibernate-configuration>
接下來看一下Hibernate進行數據庫連接的流程到底是什么樣的
Hibernate（我導入的jar包是
hibernate3.jar）在上面的那種配置之下，會有一個默認的連接池，名字叫：DriverManagerConnectionProvider；這是一個極其簡單的連接池，默認會在池中保留20個連接，這些連接不是一開始Hibernate初始化時就創建好的，而是在你需要使用連接時創建出來，使用完之后才加入到池中的。這里有一個叫closeConnection(Connection conn)的方法，這個方法將傳入的連接不做任何處理，放到池中。而這個類內部的連接池實際是一個ArrayList，每次取得時候remove掉ArrayList的第一個連接，用完后直接用add方法加入到ArrayList的最后。程序對數據庫進行操作時，Hibernate會通過
DriverManagerConnectionProvider得到一個連接Connection，在使用完之后，調用session.close()時，Hibernate會調用DriverManagerConnectionProvider的closeConnection方法（就是上面說的那個closeConnection(Connection conn)方法），這個時候，該連接會直接放到DriverManagerConnectionProvider的ArrayList中，從始至終也沒有地方去調用Connection的close方法。
我們的那個SELECT操作是定時的，而我們對數據庫的其它操作顯然并不是定時的，而這兩個操作都會向DriverManagerConnectionProvider獲取一個連接，并且工作完之后都會將自己獲得的連接放回連接池的末尾。
說到這里，問題就很明顯了,我們可以假設出現下面的場景
在
SELECT操作進行的過程中,它會持有一個連接（記為connection1），此時數據庫收到了其它的操作請求，由于此時SELECT操作還未結束，connection1并沒有放回連接池，因此這個請求會再創建一個新的連接或者拿到連接池內部的一個連接（記為connection2）這兩個操作都結束之后，connection1和connection2都被放回了連接池中，并且是放到了連接池的末尾。
**那么，下一次的SELECT操作拿到的連接到底是connection1還是connection2呢？ **
答案是都有可能，這取決于上面的場景中連接被放回連接池的順序以及兩次SELECT操作之間是否有過其它的數據庫操作，這些我們顯然無法判斷。
因此可以得出結論： 最終SELECT操作是否保持了連接的有效性我們無法判斷。
參考鏈接：
http://blog.csdn.net/nethibernate/article/details/6658855
方法二
- 延長數據庫的<b>wait_timeout</b>時間
這個方法我并沒有使用，因為wait_timeout決定的是非交互連接的時間長短。
將這個值設置得大了，可能會導致空閑連接過多。
如果你的MySQL Server有大量的閑置連接，他們不僅會白白消耗內存，而且如果連接一直在累加而不斷開，最終肯定會達到MySQL Server的連接上限數，這會報'too many connections'的錯誤。將這個值設置得小了，那就失去了使用方法二的意義。
因此可以得出結論： 方法二雖然可以解決問題，但是wait_timeout的值到底設置為多少比較合適沒有一個固定的說法，不好把握。
參考鏈接：
http://www.cnblogs.com/jiunadianshi/articles/2475475.html
http://stackoverflow.com/questions/4440336/mysql-wait-timeout
方法三
- 在程序中進行數據庫操作之前檢驗數據庫連接的有效性
這個方法雖然可行，但是過于繁瑣，因為它要確保在進行對數據庫的任何操作之前都要檢驗數據庫連接是否斷開。
我并沒有使用這個方法，因為代碼中的數據庫操作已經封裝好，再去進行修改一是麻煩，二是可能會帶來其他bug。
方法四
- 將數據庫的
autoConnect屬性設置為true
這個方法也是Google上看到的最多的方案，不過在MySQL開發者文檔中可以看到關于這個屬性的描述
The use of this feature is not recommended, because it has side effects related to session state and data consistency
并不提倡使用這個特性，因為它可能會對會話狀態和數據一致性產生副作用
到底副作用是什么，文檔上并沒有詳細說明，在stackoverflow上搜索時倒是看到了
session state and transactions cannot be maintained over a new connection.
（原有的）會話狀態和事務在新的連接中并不能被保持下來。
看到這里我就放棄了使用它的想法。
看來方法四并不能解決問題？
不過不要忘了我們是使用Hibernate框架而不是JDBC來進行數據庫操作的,既然在MySQL配置中無法解決這個問題，那么我們可以考慮一下Hibernate配置。
最終解決方案
Hibernate中恰好有類似于autoReconnect這樣的屬性來自動保持數據庫的連接，那就是使用c3p0連接池的testConnectionOnCheckout屬性。
- 數據庫自動連接的方法就是在獲取連接時檢查一下，看看該連接是否還有效，即該Connection是否已經被MySQL數據庫關閉了，如果關了就重新建立一個連接。
因此，我導入了c3p0的相關jar包，并且修改了Hibernate的配置文件
<hibernate-configuration>
<session-factory>
<!-- Database connection settings -->
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="connection.url">jdbc:mysql://localhost:3306/DatabaseName</property>
<property name="connection.characterEncoding">utf-8</property>
<property name="connection.username">root</property>
<property name="connection.password">password</property>
<!-- SQL dialect -->
<property name="dialect">org.hibernate.dialect.MySQLDialect</property>
<property name="show_sql">true</property>
<!-- c3p0連接池配置 -->
<property name="hibernate.connection.provider_class">
org.hibernate.connection.C3P0ConnectionProvider
</property>
<property name="hibernate.c3p0.max_size">20</property>
<property name="hibernate.c3p0.min_size">5</property>
<property name="hibernate.c3p0.timeout">50000</property>
<property name="hibernate.c3p0.max_statements">100</property>
<property name="hibernate.c3p0.idle_test_period">3000</property>
<!-- 當連接池耗盡并接到獲得連接的請求，則新增加連接的數量 -->
<property name="hibernate.c3p0.acquire_increment">2</property>
<property name="hibernate.c3p0.testConnectionOnCheckout">true</property>
<!--mapping files-->
......
</session-factory>
</hibernate-configuration>
上面配置中最重要的就是hibernate.c3p0.testConnectionOnCheckout這個屬性，它保證了每次取出連接時都會檢查該連接是否被關閉，如果被關閉，則重新建立連接。
至此，困擾我的這個問題就解決了，分享出解決這個問題的過程，希望對大家也能有所幫助。
參考鏈接：
http://stackoverflow.com/questions/270800/why-does-hibernate-jdbc-mysql-drop-connections-after-a-day-or-so
http://blog.csdn.net/nethibernate/article/details/6658855
http://hibernatedb.blogspot.com/2009/05/automatic-reconnect-from-hibernate-to.html
c3p0相關jar包下載地址：https://sourceforge.net/projects/c3p0/
