最近讓人頭痛的一個問題，就是伺服器在不確定的時間點會出現關於資料庫連線的Exception，大致的Exception如下：
org.hibernate.util.JDBCExceptionReporter - SQL Error:0, SQLState: 08S01 org.hibernate.util.JDBCExceptionReporter - The last packet successfully received from the server was43200 milliseconds ago. The last packet sent successfully to the server was 43200 milliseconds 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 'autoReconnect=true' to avoid this problem. org.hibernate.event.def.AbstractFlushingEventListener - Could not synchronize database state with session org.hibernate.exception.JDBCConnectionException: Could not execute JDBC batch update com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Connection.close() has already been called. Invalid operation in this state. org.hibernate.util.JDBCExceptionReporter - SQL Error:0, SQLState: 08003 org.hibernate.util.JDBCExceptionReporter - No operations allowed after connection closed. Connection was implicitly closed due to underlying exception/error: ** BEGIN NESTED EXCEPTION ** com.mysql.jdbc.exceptions.jdbc4.CommunicationsException
先說一下發生這個Exception的大致原因：
MySQL的設定中，有一個叫做「wait_timeout」的參數，這個參數大致上的意思是這樣：當一個客戶端連接到MySQL資料庫後，如果客戶端不自己斷開，也不做任何操作，MySQL資料庫會將這個連線保留"wait_timeout"這麼長時間（單位是s，預設是28800s，也就是8小時），超過這個時間之後，MySQL資料庫為了節省資源，就會在資料庫端斷開這個連線；當然，在這個過程中，如果客戶端在這個連線上有任意的操作，MySQL資料庫都會重新開始計算這個時間。
這麼看來，發生上面Exception的原因就是因為我的伺服器和MySQL資料庫的連線超過了」wait_timeout"時間，MySQL伺服器端將其斷開了，但我的程式再次使用這個連線時沒有做任何判斷，就掛了。
那這個問題要怎麼解決呢？
在想解決方案的過程中，我發現了幾個讓我不著頭緒的問題：
##第一個問題：我們的伺服器曾經在設計的過程中考慮過這個事情，所以伺服器的主執行緒有一個定時的check機制，每隔半小時會發送一個"select 1"到資料庫來保證連接是活動的，為什麼這個check機制不起作用了呢？ 第二個問題：從上面的Exception可以得到這麼一個訊息：The last packet sent successfully to the server was 43200 milliseconds ago, which is longer than the server configured value of 'wait_timeout'.
首先，MySQL資料庫那邊的解決方案很單一，就是延長」wait_timeout「的數值。 我看有的人直接就延長到一年了，也有人說這個值最大也就是21天，即使值設的再大，MySQL也就只識別21天（這個我沒有具體去MySQL的文檔中去查）。但這是治標不治本的方法，即使可以一年，也還是會有斷的時候，伺服器可是要7x24小時在線的呀。
既然MySQL資料庫那邊沒什麼好方法，接下來就只能從程式這邊來搞了。
先說說程式這邊的大致結構吧：兩個線程，一個線程負責查詢和上面說到的check機制，另一個線程負責定時更新資料庫，使用hibernate，配置很簡單，都是最基本的，沒有任何關於連接池和快取的配置，就像下面這樣：
<session-factory>
<property name="hibernate.dialect">org.hibernate.dialect.MySQL5InnoDBDialect</property>
<property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="hibernate.connection.useUnicode">true</property>
<property name="hibernate.connection.characterEncoding">UTF-8</property>
<property name="hibernate.show_sql">true</property>
<!-- 以下就全是mapping了，省略 -->
</session-factory>session = org.hibernate.SessionFactory.openSession(); transaction = session.beginTransaction(); session.update(something); transaction.commit(); session.close();
在挖掘Hibernate原始碼之前，必須先明確目標：挖掘什麼？
其實我的目標很明確，既然斷線是MySQL資料庫做的，那麼相對於我們程式這邊的問題就是我們在使用完連線後沒有呼叫Connection.close()，才會保留一個長連接在那裡。那麼，Hibernate是什麼時候開啟這個連接，又是什麼時候呼叫Connection.close()的呢？接下來就是Hibernate的原始碼挖掘中。 。 。
枯燥的過程就不說了，說說挖掘出的東西：Hibernate（忘了說了，我們用的Hibernate版本是3.3.2）在上面的在那種配置之下，會有一個預設的連接池，名字叫：DriverManagerConnectionProvider；這是一個極其簡單的連接池，預設會在池中保留20個連接，這些連接不是一開始Hibernate初始化時就創建好的，而是在你需要使用連接時創建出來，使用完之後才加入到池中的。這裡有一個叫closeConnection(Connection conn)的方法，這個方法很NB，它直接將傳入的連線不做任何處理，放到池中。而這個類別內部的連接池實際上是一個ArrayList，每次取得時候remove掉ArrayList的第一個連接，用完後直接用add方法加入到ArrayList的最後。我们的程序更新时，Hibernate会通过DriverManagerConnectionProvider得到一个连接Connection，在使用完之后，调用session.close()时，Hibernate会调用DriverManagerConnectionProvider的closeConnection方法（就是上面说的那个NB方法），这个时候，该连接会直接放到DriverManagerConnectionProvider的ArrayList中，从始至终也没有地方去调用Connection的close方法。
说到这里，问题就很明显了。
第一，我们的那个”select 1“的check机制和我们服务器程序中更新的逻辑是两个线程，check机制工作时，它会向DriverManagerConnectionProvider获取一个连接，而此时更新逻辑工作时，它会向DriverManagerConnectionProvider获取另外一个连接，两个逻辑工作完之后都会将自己获得的连接放回DriverManagerConnectionProvider的池中，而且是放到那个池的末尾。这样，check机制再想check这两个连接就需要运气了，因为更新逻辑更新完之后就把连接放回池中了，而更新逻辑是定时的，check机制也是定时的，两个定时机制如果总是能错开，那么check机制check的永远都是两个中的一个连接，另外一个就麻烦了。这也就是为什么check机制不好使的原因。
第二，关于Exception信息中那个43200毫秒的问题也就能说明白了，check机制check的总是一个连接，而另外一个过期的连接被更新线程拿跑了，并且在check机制之后没多久就有更新发生，43200毫秒恐怕就是它们之间的间隔吧。
到这里问题分析清楚了，怎么解决呢？
最容易想到的方案，也是网上说的最多的方案，就是延长MySQL端”wait_timeout“的时间。我说了，治标不治本，我觉得不爽，不用。
第二个看到最多的就是用”autoReconnect = true"这个方案，郁闷的是MySQL 5之后的数据库把这个功能给去了，说会有副作用（也没具体说有啥副作用，我也懒得查），我们用的Hibernate 3.3.2这个版本也没有autoReconnect这个功能了。
第三个说的最多的就是使用c3p0池了，况且Hibernate官网的文档中也提到，默认的那个连接池非常的屎，仅供测试使用，推荐使用c3p0（让我郁闷的是我连c3p0的官网都没找到，只在sourceForge上有个项目主页）。好吧，我就决定用c3p0来搞定这个问题。
用c3p0解决这个Exception问题
首先很明了，只要是池它就肯定有这个问题，除非在放入池之前就把连接关闭，那池还顶个屁用。所以我参考的博客里说到，最好的方式就是在获取连接时check一下，看看该连接是否还有效，即该Connection是否已经被MySQL数据库那边给关了，如果关了就重连一个。因此，按照这个思路，我修正了Hibernate的配置文件，问题得到了解决：
<session-factory>
<property name="hibernate.dialect">org.hibernate.dialect.MySQL5InnoDBDialect</property>
<property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="hibernate.connection.useUnicode">true</property>
<property name="hibernate.connection.characterEncoding">UTF-8</property>
<property name="hibernate.show_sql">true</property>
<!-- c3p0在我们使用的Hibernate版本中自带，不用下载，直接使用 -->
<property name="hibernate.connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
<property name="hibernate.c3p0.min_size">5</property>
<property name="hibernate.c3p0.max_size">20</property>
<property name="hibernate.c3p0.timeout">1800</property>
<property name="hibernate.c3p0.max_statements">50</property>
<!-- 下面这句很重要，后面有解释 -->
<property name="hibernate.c3p0.testConnectionOnCheckout">true</property>
<!-- 以下就全是mapping了，省略 -->
</session-factory>上面配置中最重要的就是hibernate.c3p0.testConnectionOnCheckout这个属性，它保证了我们前面说的每次取出连接时会检查该连接是否被关闭了。不过这个属性会对性能有一些损耗，引用我参考的博客上得话：程序能用是第一，之后才是它的性能（又不是不能容忍）。
当然，c3p0自带类似于select 1这样的check机制，但是就像我说的，除非你将check机制的间隔时间把握的非常好，否则，问题是没有解决的。
好了，至此，困扰我的问题解决完了。希望上面的这些整理可以为我以后碰到类似的问题留个思路，也可以为正在被此问题困扰的人提供一丝帮助
以上是MySQL之-使用Hibernate連接MySQL資料庫時連接逾時斷開的問題解決方法的詳細內容。更多資訊請關注PHP中文網其他相關文章！
