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 구성에는 "wait_timeout"이라는 매개변수가 있습니다. 이 매개변수의 일반적인 의미는 다음과 같습니다. 클라이언트가 MySQL 데이터베이스에 연결할 때. 클라이언트가 아무런 작업도 하지 않고 직접 연결을 끊으면 MySQL 데이터베이스는 오랫동안 "wait_timeout" 동안 연결을 유지합니다(단위는 s, 기본값은 28800s, 이 시간 이후 8시간입니다). 초과되면 리소스를 절약하기 위해 MySQL 데이터베이스는 데이터베이스 측에서 연결이 끊어집니다. 물론 이 프로세스 중에 클라이언트가 이 연결에서 작업을 수행하면 MySQL 데이터베이스가 시간 계산을 다시 시작합니다.

위 예외가 발생한 이유는 내 서버와 MySQL 데이터베이스 간의 연결이 "wait_timeout" 시간을 초과하여 MySQL 서버가 연결을 끊었기 때문인 것 같습니다. 그런데 내 프로그램이 이 연결을 다시 사용하면 아무런 판단도 하지 않아서 전화를 끊었습니다.

그럼 이 문제를 어떻게 해결해야 할까요?

해결책을 고민하던 중 몇 가지 혼란스러운 문제를 발견했습니다.

첫 번째 문제: 우리 서버는 설계 과정에서 이 문제를 고려했기 때문에 서버의 메인 스레드에는 연결이 활성화되었는지 확인하기 위해 30분마다 "select 1"을 데이터베이스로 보내는 예약된 확인 메커니즘이 작동하지 않는 이유는 무엇입니까?

두 번째 질문: 위의 예외에서 다음 정보를 얻을 수 있습니다.

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년 동안 사용할 수 있더라도 서버는 연중무휴 온라인 상태여야 합니다.

MySQL 데이터베이스 측에서는 좋은 방법이 없기 때문에 다음 단계는 프로그램 측에서 하는 것입니다.

먼저 프로그램의 일반적인 구조에 대해 이야기해 보겠습니다. 두 개의 스레드 중 하나는 위에서 언급한 쿼리 및 확인 메커니즘을 담당하고, 다른 스레드는 정기적으로 데이터베이스 업데이트를 담당합니다. 가장 기본은 다음과 같이 연결 풀과 캐시에 대한 구성이 없습니다.

<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();

여기서 데이터베이스 Connection의 연결과 종료에 대한 모든 것은 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를 통해 연결을 얻습니다. 이를 사용한 후 session.close()를 호출하면 Hibernate는 DriverManagerConnectionProvider의 closeConnection 메소드(위에서 언급한 NB 메소드)를 호출합니다. 이때 연결은 DriverManagerConnectionProvider의 ArrayList에 직접 배치되며 처음부터 끝까지 Connection의 닫기 메서드를 호출할 수 있는 위치가 없습니다.

이 시점에서 문제는 명백하다.

第一，我们的那个”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）！