MySQL - Hibernate를 사용하여 MySQL 데이터베이스에 연결할 때 연결 시간 초과 및 연결 끊김 문제에 대한 솔루션

최근 문제가 되는 것은 불확실한 시간에 데이터베이스 연결에 대해 서버에서 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

먼저 이 예외가 발생하는 일반적인 이유:

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의 소스코드를 파헤쳐 보지 않을 수 없습니다.

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 데이터베이스에 연결할 때 연결 시간 초과 및 연결 끊김 문제에 대한 솔루션의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!