MySQL - Hibernate を使用して MySQL データベースに接続すると、MySQL 接続がタイムアウトして切断される

最近の厄介な問題は、サーバーが不確実なタイミングでデータベース接続に関連する例外を発生させることです。一般的な例外は次のとおりです:

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

まず、この例外の一般的な理由について説明します。このパラメータの一般的な意味は次のとおりです。クライアントが MySQL データベースに接続するときに、クライアントが切断しないか、操作を実行しない場合、MySQL データベースは接続を終了します。 「wait_timeout」を長時間 (単位は s、デフォルトは 28800 秒、つまり 8 時間) を超えると、MySQL データベースはリソースを節約するためにデータベース側の接続を切断します。このプロセス中に、クライアントがこの接続に対して何らかの操作を実行すると、MySQL データベースは今度は計算を再開します。

上記の例外が発生した原因は、サーバーとMySQLデータベース間の接続が「wait_timeout」時間を超えてMySQLサーバーが接続を切断したためと思われますが、この接続を再度使用するときに私のプログラムが何も判断しなかったためです。 . ということで電話を切りました。

では、この問題を解決するにはどうすればよいでしょうか?

解決策を考える過程で、私を混乱させるいくつかの問題を発見しました:

最初の質問: 私たちのサーバーは設計プロセス中にこの問題を検討してきたため、サーバーのメインスレッドにはスケジュールされたチェックメカニズムがあります接続がアクティブであることを確認するために、30 分ごとにデータベースに「select 1」が送信されます。このチェック メカニズムが機能しないのはなぜですか?

2 番目の質問: 上記の例外から、次の情報を取得できます:

The last packet sent successfully to the server was 43200 milliseconds ago, which is longer than the server configured value of 'wait_timeout'.

この情報は、サーバーに正常に送信された最後のパケットは 43200 ミリ秒前であることが非常に明確です。しかし、43200 ミリ秒はわずか 43.2 秒です。つまり、サーバーは 43.2 秒前にのみ MySQL サーバーと通信したことになります。「wait_timeout」を超える問題はどのようにして発生するのでしょうか。さらに、MySQL データベースの構成は確かに 28800 秒 (8 時間) です。これは別の状況ですか?

私は長い間ネットでグーグル検索してきましたが、この問題についてはたくさんの議論がありますが、グーグルの結果に基づいて自分でそれを理解することしかできず、効果的だと思われる方法は見つかりませんでした。

まず、MySQL データベース側の解決策は非常に簡単で、「wait_timeout」の値を拡張することです。直接 1 年に延長する人もいれば、最大値が 21 日であるという人もいます。値をより大きな値に設定しても、MySQL は 21 日しか認識しません (これについては特に確認しませんでした)。 MySQL のドキュメント)。ただし、これは永続的な解決策ではなく、1 年間使用できたとしても、サーバーは 24 時間年中無休でオンラインになっている必要があります。

MySQLデータベース側で良い方法がないので、次のステップはプログラム側から行うことです。

まずプログラムの一般的な構造について説明します。2 つのスレッドで、1 つのスレッドはクエリと上記のチェック メカニズムを担当し、もう 1 つのスレッドはデータベースの定期的な更新を担当します。休止状態を使用すると、構成は非常にシンプルです。は最も基本的なもので、次のように接続プールとキャッシュに関する設定はありません:

<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 では、いいえ、Hibernate のソース コードを詳しく調べることは不可能です。

休止状態のソース コードをマイニングする前に、明確な目標を設定する必要があります。「何をマイニングするか?」

実際、私の目標は非常に明確です。切断は MySQL データベースによって行われるため、このプログラムの問題は、接続を使用した後に Connection.close() を呼び出さないことであり、その結果、長い接続が保持されることになります。 。 そこには。では、Hibernate がこの接続をオープンしたのはいつですか、また、Connection.close() を呼び出したのはいつでしょうか?

次のステップは、Hibernate のソース コードを詳しく調べることです。 。 。

退屈なプロセスについては話しませんが、私が見つけたものについて話しましょう:

Hibernate (言及するのを忘れていました、私たちが使用した Hibernate のバージョンは 3.3.2 です)。デフォルトの接続プール (名前は DriverManagerConnectionProvider)。これは非常に単純な接続プールで、デフォルトでは 20 個の接続がプール内に予約されます。これらの接続は、Hibernate の初期化時には作成されませんが、必要なときに作成されます。接続。使用後にプールに追加されます。 closeConnection(Connection conn) というメソッドがあります。このメソッドは、受信接続を処理せずに直接プールに入れます。このクラス内の接続プールは実際には ArrayList であり、取得されるたびに、使用後に 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数据库，MySQL连接超时断开的问题的内容，更多相关内容请关注PHP中文网（www.php.cn）！