MySQL – Wenn Sie Hibernate verwenden, um eine Verbindung zur MySQL-Datenbank herzustellen, läuft die MySQL-Verbindung ab und wird getrennt

Eines der jüngsten Probleme besteht darin, dass der Server zu einem ungewissen Zeitpunkt eine Ausnahme bezüglich der Datenbankverbindung haben wird. Die allgemeine Ausnahme lautet wie folgt:

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

Lassen Sie mich zunächst über den allgemeinen Grund dafür sprechen Diese Ausnahme. :

In der Konfiguration von MySQL gibt es einen Parameter namens „wait_timeout“. Die allgemeine Bedeutung dieses Parameters ist diese: wenn ein Client eine Verbindung zu MySQL herstellt Datenbank, wenn der Client die Verbindung nicht selbst trennt oder keine Vorgänge ausführt. Die MySQL-Datenbank hält die Verbindung so lange aufrecht (Einheit ist s, der Standardwert ist 28800s, also 8 Stunden). Wenn die MySQL-Datenbank überschritten wird, wird die Verbindung auf der Datenbankseite getrennt. Wenn der Client während dieses Vorgangs Operationen an dieser Verbindung durchführt, wird die MySQL-Datenbank erneut berechnet .

Es scheint, dass der Grund für das Auftreten der oben genannten Ausnahme darin liegt, dass die Verbindung zwischen meinem Server und der MySQL-Datenbank die „wait_timeout“-Zeit überschritten hat und der MySQL-Server sie getrennt hat, aber wenn mein Programm diese Verbindung wieder verwendet, habe ich Ich habe kein Urteil gefällt, also habe ich aufgelegt.

Wie kann man dieses Problem lösen?

Während ich über Lösungen nachdachte, stieß ich auf mehrere Probleme, die mich verwirrten:

Das erste Problem: Unser Server hatte diese Angelegenheit während des Designprozesses berücksichtigt, sodass der Hauptthread des Servers geplant ist Prüfmechanismus, der jede halbe Stunde eine „select 1“ an die Datenbank sendet, um sicherzustellen, dass die Verbindung aktiv ist. Warum funktioniert dieser Prüfmechanismus nicht?

Zweite Frage: Aus der obigen Ausnahme können wir diese Informationen erhalten:

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

Diese Informationen sind sehr klar. Das letzte Paket wurde vor 43200 Millisekunden erfolgreich gesendet. Aber 43200 Millisekunden sind nur 43,2 Sekunden, was bedeutet, dass unser Server erst vor 43,2 Sekunden mit dem MySQL-Server kommuniziert hat. Wie konnte das Problem der Überschreitung von „wait_timeout“ auftreten? Darüber hinaus beträgt die Konfiguration der MySQL-Datenbank tatsächlich 28800 Sekunden (8 Stunden). Ist das eine andere Situation?

Ich habe lange im Internet gegoogelt und es gibt einige Diskussionen zu diesem Thema, aber ich habe noch nie eine Methode gefunden, die meiner Meinung nach effektiv ist. Ich kann nur langsam darüber nachdenken Kombinieren der Ergebnisse von Google.

Zuallererst ist die Lösung auf der MySQL-Datenbankseite sehr einfach, nämlich den Wert von „wait_timeout“ zu erweitern. Ich habe einige Leute gesehen, die es direkt auf ein Jahr erweitert haben, und einige Leute sagen, dass der Maximalwert 21 Tage beträgt. Selbst wenn der Wert auf einen größeren Wert eingestellt ist, erkennt MySQL nur 21 Tage (ich habe dies nicht speziell überprüft). MySQL-Dokumentation). Dies ist jedoch eher eine vorübergehende Lösung als eine dauerhafte Lösung. Auch wenn es ein Jahr lang verwendet werden kann, wird es dennoch zu Unterbrechungen kommen. Der Server muss rund um die Uhr online sein.

Da es auf der MySQL-Datenbankseite keine gute Methode gibt, besteht der nächste Schritt darin, dies von der Programmseite aus zu tun.

Lassen Sie uns zunächst über die allgemeine Struktur des Programms sprechen: Zwei Threads, ein Thread ist für die Abfrage und den oben erwähnten Prüfmechanismus verantwortlich, und der andere Thread ist für die regelmäßige Aktualisierung der Datenbank mithilfe des Ruhezustands verantwortlich ist sehr einfach. Im Grunde gibt es keine Konfiguration für den Verbindungspool und den Cache, genau wie folgt:

<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>

Der Aktualisierungsprozess im Programm sieht ungefähr so ​​aus:

session = org.hibernate.SessionFactory.openSession();  
transaction = session.beginTransaction();  
session.update(something);  
transaction.commit();  
session.close();

Hier befinden sich alle Verbindungen und Schließungen im Zusammenhang mit der Datenbankverbindung im Ruhezustand, sodass es unmöglich ist, nicht in den Quellcode von Ruhezustand einzutauchen.

Vor dem Mining des Hibernate-Quellcodes muss das Ziel klar sein: Was soll geschürft werden?

Tatsächlich ist mein Ziel sehr klar. Da die Trennung von der MySQL-Datenbank durchgeführt wird, besteht das Problem mit unserem Programm darin, dass wir Connection.close() nicht aufrufen, nachdem die Verbindung verwendet wurde Es besteht eine lange Verbindung. Wann hat Hibernate diese Verbindung geöffnet und wann Connection.close() aufgerufen?

Der nächste Schritt besteht darin, in den Quellcode von Hibernate einzutauchen. . .

Ich werde nicht über den langweiligen Prozess sprechen, aber lasst uns über das sprechen, was ich entdeckt habe:

Hibernate (ich habe vergessen zu erwähnen, die Hibernate-Version, die wir verwendet haben, ist 3.3.2) hat das Die obige Konfiguration enthält einen Standardverbindungspool mit dem Namen: DriverManagerConnectionProvider. Dies ist ein äußerst einfacher Verbindungspool. Standardmäßig werden 20 Verbindungen im Pool reserviert. Diese Verbindungen werden nicht erstellt, wenn Hibernate initialisiert wird wird erstellt, wenn Sie die Verbindung verwenden müssen, und wird nach der Verwendung dem Pool hinzugefügt. Es gibt eine Methode namens closeConnection(Connection conn). Diese Methode stellt die eingehende Verbindung direkt und ohne Verarbeitung in den Pool. Der Verbindungspool innerhalb dieser Klasse ist eigentlich eine ArrayList. Bei jedem Abrufen wird die erste Verbindung der ArrayList entfernt. Nach der Verwendung wird sie mithilfe der Add-Methode direkt am Ende der ArrayList hinzugefügt.

Wenn unser Programm aktualisiert wird, erhält Hibernate eine Verbindungsverbindung über DriverManagerConnectionProvider. Nach der Verwendung ruft Hibernate beim Aufruf von session.close() die closeConnection-Methode von DriverManagerConnectionProvider (die oben erwähnte NB-Methode) auf Dieses Mal wird die Verbindung direkt in die ArrayList von DriverManagerConnectionProvider eingefügt, und es gibt keinen Ort, an dem die Close-Methode von Connection von Anfang bis Ende aufgerufen werden kann.

An diesem Punkt ist das Problem offensichtlich.

第一，我们的那个”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中文网（m.sbmmt.com）！