MySQL - Solution au problème de délai d'expiration et de déconnexion lors de l'utilisation d'Hibernate pour se connecter à la base de données MySQL

Un problème gênant récemment est que le serveur aura une Exception concernant la connexion à la base de données à un moment incertain. L'exception générale est la suivante :

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

Parlons-en. la raison générale pour laquelle cette exception s'est produite :

Dans la configuration de MySQL, il existe un paramètre appelé "wait_timeout". La signification générale de ce paramètre est la suivante : lorsqu'un client se connecte à Après. la base de données MySQL , si le client ne se déconnecte pas ou n'effectue aucune opération, la base de données MySQL conservera la connexion pendant "wait_timeout" pendant aussi longtemps (l'unité est s, la valeur par défaut est 28800s, soit 8 heures), et dépasse Passé ce délai, afin d'économiser des ressources, la base de données MySQL déconnectera la connexion côté base de données ; bien entendu, pendant ce processus, si le client effectue des opérations sur cette connexion, la base de données MySQL redémarrera le calcul de ce temps.

Il semble que la raison pour laquelle l'exception ci-dessus s'est produite est que la connexion entre mon serveur et la base de données MySQL a dépassé le temps "wait_timeout" et que le serveur MySQL l'a déconnecté, mais lorsque mon programme utilise à nouveau cette connexion, je Je n'ai porté aucun jugement, alors j'ai raccroché.

Alors comment résoudre ce problème ?

En réfléchissant aux solutions, j'ai trouvé plusieurs problèmes qui m'ont dérouté :

Le premier problème : notre serveur a été conçu. Cette question a été prise en compte pendant le processus, donc le principal Le thread du serveur dispose d'un mécanisme de vérification planifié, qui envoie un « select 1 » à la base de données toutes les demi-heures pour garantir que la connexion est active. Pourquoi ce mécanisme de vérification ne fonctionne-t-il pas ?

Deuxième question : à partir de l'exception ci-dessus, nous pouvons obtenir ces informations :

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

Cette information est très claire. Le dernier paquet envoyé avec succès au serveur remonte à 43 200 millisecondes. Mais 43 200 millisecondes ne représentent que 43,2 secondes, ce qui signifie que notre serveur n'a communiqué avec le serveur MySQL qu'il y a 43,2 secondes. Comment le problème de dépassement du "wait_timeout" a-t-il pu se produire ? De plus, la configuration de la base de données MySQL est bien de 28800 secondes (8 heures). Est-ce une autre situation ?

Je cherche sur Internet depuis longtemps, et il y a pas mal de discussions sur cette question, mais je n'ai jamais trouvé de méthode que je pense efficace, je ne peux y réfléchir que lentement. combinant les résultats de Google.

Tout d'abord, la solution côté base de données MySQL est très simple, elle consiste à étendre la valeur de "wait_timeout". J'ai vu certaines personnes l'étendre directement à un an, et certaines personnes disent que la valeur maximale est de 21 jours. Même si la valeur est définie sur une valeur plus grande, MySQL ne reconnaîtra que 21 jours (je n'y suis pas spécifiquement allé). à la documentation MySQL pour cela) Vérifiez-le). Mais il s'agit d'une solution temporaire plutôt que permanente. Même s'il peut être utilisé pendant un an, il y aura toujours des interruptions. Le serveur doit être en ligne 24h/24 et 7j/7.

Comme il n'y a pas de bonne méthode du côté de la base de données MySQL, l'étape suivante consiste à le faire du côté du programme.

Parlons d'abord de la structure générale du programme : deux threads, un thread est responsable des requêtes et du mécanisme de vérification mentionné ci-dessus, et l'autre thread est responsable de la mise à jour régulière de la base de données en utilisant la mise en veille prolongée. , la configuration est très simple. , la plus basique, sans aucune configuration sur le pool de connexions et le cache, tout comme ce qui suit :

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

Le processus de mise à jour dans le programme est à peu près comme ceci :

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

Ici, toutes les connexions et fermetures liées à la base de données Connection sont en Hibernate, il est donc impossible de ne pas fouiller dans le code source d'Hibernate.

Avant d'exploiter le code source d'Hibernate, l'objectif doit être clair : que miner ?

En fait, mon objectif est très clair. Puisque la déconnexion est effectuée par la base de données MySQL, le problème avec notre programme est que nous n'avons pas appelé Connection.close() après avoir utilisé la connexion uniquement. alors une longue connexion y sera maintenue. Alors, quand Hibernate a-t-il ouvert cette connexion et quand a-t-il appelé Connection.close() ?

L'étape suivante consiste à fouiller dans le code source d'Hibernate. . .

Je ne parlerai pas du processus ennuyeux, mais parlons de ce qui a été exhumé :

Hibernate (j'ai oublié de le mentionner, la version Hibernate que nous avons utilisée est la 3.3.2 ) ci-dessus Sous cette configuration, il y aura un pool de connexions par défaut nommé : DriverManagerConnectionProvider ; il s'agit d'un pool de connexions extrêmement simple qui conservera 20 connexions dans le pool par défaut. Ces connexions ne sont pas créées lors de l'initialisation d'Hibernate, mais créées lorsque vous le faites. besoin d'utiliser la connexion et ajouté à la piscine après utilisation. Il existe une méthode appelée closeConnection(Connection conn). Cette méthode est très NB : elle met directement la connexion entrante dans le pool sans aucun traitement. Le pool de connexions à l'intérieur de cette classe est en fait une ArrayList. A chaque obtention, la première connexion de l'ArrayList est supprimée. Après utilisation, elle est directement ajoutée à la fin de l'ArrayList à l'aide de la méthode add.

我们的程序更新时，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机制的间隔时间把握的非常好，否则，问题是没有解决的。

好了，至此，困扰我的问题解决完了。希望上面的这些整理可以为我以后碰到类似的问题留个思路，也可以为正在被此问题困扰的人提供一丝帮助

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!