通过休眠恢复破损的数据库连接 [英] Recovering from broken database connection with hibernate
问题描述
我无法从损坏的数据库连接恢复。我的测试用例使用以下库。
guice-persist 4.0
Hibernate核心4.3.1
HikariCP-java6-2.3.9（连接池）。
我的测试在循环中运行一个简单的读取，每次读取之间有一个小的睡眠。
@ com.google.inject.persist.Transactional
保护无效simpleRead（）{
dao =新的MyDao（....）
dao.findBy（...）
}
$ b $
@Inject
受保护的com.google.inject.Provider< / p>的EntityManager> EntityManager的;
guice模块像这样绑定
@Override
public void configure（）{
install（new JpaPersistModule（test））;
bind（JPAInitializer.class）.asEagerSingleton（）;
}
我的persistence.xml将事务类型定义为RESOURCE-LOCAL。
我有几个hikari设置，但林不知道这些是相关的。 code>< property name =hibernate.connection.provider_classvalue =com.zaxxer.hikari.hibernate.HikariConnectionProvider/>
< property name =hibernate.hikari.maxLifetimevalue =1800000/>
< property name =hibernate.hikari.connectionTestQueryvalue =SELECT 1/>
< property name =hibernate.hikari.leakDetectionThresholdvalue =300000/>
在测试循环读取时，我通过停止任务管理器的服务来中断SQLServer连接。如果循环不在simpRead（）方法中，那么它将在下次尝试读取时正常处理错误，并在服务再次启动时重新连接。
但是，如果服务停止时它在simpleRead（）方法中，则它将失败并且不会恢复。第一次失败的报告如下：
$ b org.hibernate.TransactionException：JDBC开始事务失败：
javax.persistence.PersistenceException：org.hibernate.TransactionException：JDBC开始事务失败：
在org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert（AbstractEntityManagerImpl.java:1763）
在org.hibernate.jpa .spi.AbstractEntityManagerImpl.convert（AbstractEntityManagerImpl.java:1677）
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException（AbstractEntityManagerImpl.java:1771）
at org.hibernate.jpa.internal.TransactionImpl .begin（TransactionImpl.java:64）
在com.google.inject.persist.jpa.JpaLocalTxnInterceptor.invoke（JpaLocalTxnInterceptor.java:66）
在net.impro.portal.server.model.dao .TestConnectionStuff.testConnectionBroken（TestConnectionStuff.java:40）
at sun.reflect.NativeMethodAccessorImpl.invoke0（Native Method）
at sun.reflect.NativeMet hodAccessorImpl.invoke（来源不明）在sun.reflect.DelegatingMethodAccessorImpl.invoke
（来源不明）在java.lang.reflect.Method.invoke
（来源不明）
。在org.testng。内部.MethodInvocationHelper.invokeMethod（MethodInvocationHelper.java:80）
在org.testng.internal.Invoker.invokeMethod（Invoker.java:714）
在org.testng.internal.Invoker.invokeTestMethod（Invoker。
at org.testng.internal.Invoker.invokeTestMethods（Invoker.java:1231）
at org.testng.internal.TestMethodWorker.invokeTestMethods（TestMethodWorker.java:127）
在org.testng.internal.TestMethodWorker.run（TestMethodWorker.java:111）
在org.testng.TestRunner.privateRun（TestRunner.java:767）
在org.testng.TestRunner.run（TestRunner的.java：617）
在org.testng.SuiteRunner.runTest（SuiteRunner.java:334）
在org.testng.SuiteRunner.runSequentially（SuiteRunner.java:329）
。在组织。 testng.SuiteRunner.privateRun（SuiteRunner.java:29 1）在org.testng.SuiteRunner.run（SuiteRunner.java:240
）中在org.testng.SuiteRunnerWorker.runSuite（SuiteRunnerWorker.java:52
）
。在org.testng.SuiteRunnerWorker .RUN（SuiteRunnerWorker.java:86）
在org.testng.TestNG.runSuitesSequentially（TestNG.java:1197）
在org.testng.TestNG.runSuitesLocally（TestNG.java:1122）
在org.testng.TestNG.run（TestNG.java:1030）
在org.testng.remote.RemoteTestNG.run（RemoteTestNG.java:111）
在org.testng.remote.RemoteTestNG。 initAndRun（RemoteTestNG.java:204）
在org.testng.remote.RemoteTestNG.main（RemoteTestNG.java:175）
导致：org.hibernate.TransactionException：JDBC开始事务失败：
org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin（AbstractTransactionImpl.java:162）$ b $ or $。$ b $ org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin（JdbcTransaction.java:76）
在org.hibernate.internal.SessionImpl.beginTransaction（SessionImpl.j ava：1431）
在org.hibernate.jpa.internal.TransactionImpl.begin（TransactionImpl.java:61）
... 26 more
导致：java.sql.SQLException：I / O错误：通过peer重置的连接：套接字写入错误$ b $ net.sourceforge.jtds.jdbc.TdsCore.executeSQL（TdsCore.java:1059）$ b $ net.sourceforge.jtds.jdbc.TdsCore。 submitSQL处com.zaxxer.hikari.proxy.ConnectionProxy.setAutoCommit net.sourceforge.jtds.jdbc.JtdsConnection.setAutoCommit（JtdsConnection.java:2291）
（TdsCore.java:905）
（ConnectionProxy。 Java的：334），美元，com.zaxxer.hikari.proxy.ConnectionJavassistProxy.setAutoCommit（ConnectionJavassistProxy.java b $ b）
在org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin（JdbcTransaction.java： 72）
... 29 more
导致：java.net.SocketException：由peer重置的连接：套接字写入错误$ b $在java.net.SocketOutputStream.socketWrite0（本地方法）$ b在java.net.SocketOutputStream.socketWrite处为$ b（Unknown Sou rce）
在java.net.SocketOutputStream.write（未知源）
在java.io.DataOutputStream.write（未知源）
在net.sourceforge.jtds.jdbc.SharedSocket.sendNetPacket （SharedSocket.java:717）
at net.sourceforge.jtds.jdbc.RequestStream.putPacket（RequestStream.java:570）
at net.sourceforge.jtds.jdbc.RequestStream.flush（RequestStream.java ：518）
at net.sourceforge.jtds.jdbc.TdsCore.executeSQL（TdsCore.java:1046）
... 34 more
...
因为现在没有正确清理，后续的请求会失败，如
org.hibernate.TransactionException：已经有一个关联的托管连接
Im不容易确定哪个层负责这个问题。从我读过的内容来看，连接池应该测试断开的连接并清理干净的东西，但是我怀疑它的guice-persist永远有与它的线程本地对象相关的破坏的EntityManager引用。当然，这也可能是我使用它们的方式。
编辑
经过进一步调查，我注意到如果我在每次测试读取之间等待> 1000ms，那么代码的行为如预期。我得到下面的StackTrace，然后在恢复SQLServer服务之后，它很高兴地重新连接。小于1000ms的任何内容，我会在原始帖子中看到上面列出的错误。看起来hibernate没有以相同的方式处理IO /错误，并且连接永远处于断开状态。
javax .persistence.QueryTimeoutException：无法在org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert（AbstractEntityManagerImpl.java:1725）处打开连接
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert处的
（AbstractEntityManagerImpl .java：1677）
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException（AbstractEntityManagerImpl.java:1771）
at org.hibernate.jpa.internal.TransactionImpl.begin（TransactionImpl.java:64 ）美元，com.google.inject.persist.jpa.JpaLocalTxnInterceptor.invoke（JpaLocalTxnInterceptor.java:66 b $ b）
在net.impro.portal.server.model.dao.TestConnectionStuff.testConnectionBroken（TestConnectionStuff.java ：40）
at sun.reflect.NativeMethodAccessorImpl.invoke0（Native Method）
at sun.reflect.NativeMethodAccessorImpl.invoke（Unknown Source）
在sun.reflect.DelegatingMethodAccessorImpl.invoke（未知源）
在java.lang.reflect.Method.invoke（未知源）
在org.testng.internal.MethodInvocationHelper.invokeMethod（MethodInvocationHelper.java:80 ）
处org.testng.internal.Invoker.invokeTestMethod（Invoker.java:901）
org.testng.internal.Invoker.invokeMethod（Invoker.java:714）
。在组织。 testng.internal.Invoker.invokeTestMethods（Invoker.java:1231）
at org.testng.internal.TestMethodWorker.invokeTestMethods（TestMethodWorker.java:127）
at org.testng.internal.TestMethodWorker.run（ TestMethodWorker.java:111）
在org.testng.TestRunner.privateRun（TestRunner.java:767）
在org.testng.TestRunner.run（TestRunner.java:617）
。在组织.testng.SuiteRunner.runTest（SuiteRunner.java:334）
at org.testng.SuiteRunner.runSequentially（SuiteRunner.java:329）
at org.testng.SuiteRunner.privateRun（SuiteRunner.java:291 ）
在org.testng.SuiteRunner.run（Su iteRunner.java:240）
在org.testng.SuiteRunnerWorker.runSuite（SuiteRunnerWorker.java:52）
在org.testng.SuiteRunnerWorker.run（SuiteRunnerWorker.java:86）
。在组织.testng.TestNG.runSuitesSequentially（TestNG.java:1197）
在org.testng.TestNG.runSuitesLocally（TestNG.java:1122）
在org.testng.TestNG.run（TestNG.java:1030 ）
处org.testng.remote.RemoteTestNG.initAndRun（RemoteTestNG.java:204）
org.testng.remote.RemoteTestNG.run（RemoteTestNG.java:111）
。在组织。 testng.remote.RemoteTestNG.main（RemoteTestNG.java:175）
产生的原因：org.hibernate.QueryTimeoutException：无法打开连接在$ org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert（SQLExceptionTypeDelegate b $湾的java：在org.hibernate.exception.internal.StandardSQLExceptionConverter.convert（StandardSQLExceptionConverter.java:49 83）
）
。在org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert（SqlExceptionHelper.java： 126）
在org .hibernate.engine.jdbc.spi.SqlExceptionHelper.convert（SqlExceptionHelper.java:112）
at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection（LogicalConnectionImpl.java:235）
at org .hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection（LogicalConnectionImpl.java:171）
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin（JdbcTransaction.java:67）
org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin（AbstractTransactionImpl.java:162）
at org.hibernate.internal.SessionImpl.beginTransaction（SessionImpl.java:1471）
at org.hibernate .jpa.internal.TransactionImpl.begin（TransactionImpl.java:61）
... 26 more
引起：java.sql.SQLTimeoutException：等待连接30004ms后超时。
at com.zaxxer.hikari.pool.BaseHikariPool.getConnection（BaseHikariPool.java:233）
at com.zaxxer.hikari.pool.BaseHikariPool.getConnection（BaseHikariPool.java:183）
在com.zaxxer.hikari.HikariDataSource.getConnection（HikariDataSource.java:93）
在com.zaxxer.hikari.hibernate.HikariConnectionProvider.getConnection（HikariConnectionProvider.java:101）
在org.hibernate.internal .AbstractSessionImpl $ NonContextualJdbcConnectionAccess.obtainConnection（AbstractSessionImpl.java:380）
在org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection（LogicalConnectionImpl.java:228）
... 31个
导致：java.sql.SQLException：网络错误IOException：连接被拒绝：在net.sourceforge.jtds.jdbc.JtdsConnection中连接
。< init>（JtdsConnection.java:436）
at net .sourceforge.jtds.jdbc.Driver.connect（Driver.java:184）
at com.zaxxer.hikari.util.DriverDataSource.getConnection（DriverDataSource.java:95）
at com.zaxxer.hikari.util.DriverDataSource.getConnection（DriverDataSource.java:101）
at com.zaxxer.hikari.pool.BaseHikariPool.addConnection（BaseHikariPool.java:444）
在com.zaxxer.hikari.pool.BaseHikariPool $ 1.run（BaseHikariPool.java:419）$ b $在java.util.concurrent.Executors $ RunnableAdapter.call（来源不明）
在java.util.concurrent中的b .FutureTask.run（未知源）
位于java.util.concurrent.ThreadPoolExecutor.runWorker（未知源）
位于java.util.concurrent.ThreadPoolExecutor $ Worker.run（未知源）
在java.lang.Thread.run（Unknown Source）
导致：java.net.ConnectException：连接被拒绝：在java.net.DualStackPlainSocketImpl.waitForConnect上连接
（原生方法）
at java.net.DualStackPlainSocketImpl.socketConnect（未知源）
at java.net.AbstractPlainSocketImpl.doConnect（未知源）
at java.net.AbstractPlainSocketImpl.connectToAddress（未知源）
at ja va.net.AbstractPlainSocketImpl.connect（未知源）
在java.net.PlainSocketImpl.connect（未知源）
在java.net.SocksSocketImpl.connect（未知源）
在java。 net.Socket.connect（未知来源）
。在net.sourceforge.jtds.jdbc.SharedSocket.createSocketForJDBC3（SharedSocket.java:288）在net.sourceforge.jtds.jdbc.SharedSocket
将。INIT> ;（SharedSocket.java:251）
at net.sourceforge.jtds.jdbc.JtdsConnection。< init>（JtdsConnection.java:331）
... 10 more
解决方案 / b>
$ b 没有任何合理的解决方法。/ hibernate / hibernate / hibernate / hibernate / hibernate / ，数据库恢复似乎不可能或至少非常不切实际。
I am having trouble recovering from a broken database connection. My test case uses the following libraries.
guice-persist 4.0
Hibernate core 4.3.1
HikariCP-java6-2.3.9 (connection pool).
My test runs a simple read in a loop with a small sleep between each read.
@com.google.inject.persist.Transactional
protected void simpleRead() {
dao = new MyDao(....)
dao.findBy(...)
}
The Dao acquires its entityManager like this
@Inject
protected com.google.inject.Provider<EntityManager> entityManager;
The guice module is bound like this
@Override
public void configure() {
install(new JpaPersistModule("test"));
bind(JPAInitializer.class).asEagerSingleton();
}
My persistence.xml defines the transaction-type as "RESOURCE-LOCAL".
And I have a few hikari settings, but Im not sure if these are relevant
<property name="hibernate.connection.provider_class" value="com.zaxxer.hikari.hibernate.HikariConnectionProvider" />
<property name="hibernate.hikari.maxLifetime" value="1800000" />
<property name="hibernate.hikari.connectionTestQuery" value="SELECT 1" />
<property name="hibernate.hikari.leakDetectionThreshold" value="300000" />
While the test is looping through the reads, I break the SQLServer connection by stopping the service from task manager. If the loop was not in the simplRead() method, at the time, it gracefully handles the error on the next attempted read and re-connects when the service is started again.
However, if it was in the simpleRead() method when the service is stopped, it fails and never recovers. The first failure is reported as follows
org.hibernate.TransactionException: JDBC begin transaction failed:
javax.persistence.PersistenceException: org.hibernate.TransactionException: JDBC begin transaction failed:
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1771)
at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:64)
at com.google.inject.persist.jpa.JpaLocalTxnInterceptor.invoke(JpaLocalTxnInterceptor.java:66)
at net.impro.portal.server.model.dao.TestConnectionStuff.testConnectionBroken(TestConnectionStuff.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1197)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1122)
at org.testng.TestNG.run(TestNG.java:1030)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
Caused by: org.hibernate.TransactionException: JDBC begin transaction failed:
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:76)
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162)
at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1431)
at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:61)
... 26 more
Caused by: java.sql.SQLException: I/O Error: Connection reset by peer: socket write error
at net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCore.java:1059)
at net.sourceforge.jtds.jdbc.TdsCore.submitSQL(TdsCore.java:905)
at net.sourceforge.jtds.jdbc.JtdsConnection.setAutoCommit(JtdsConnection.java:2291)
at com.zaxxer.hikari.proxy.ConnectionProxy.setAutoCommit(ConnectionProxy.java:334)
at com.zaxxer.hikari.proxy.ConnectionJavassistProxy.setAutoCommit(ConnectionJavassistProxy.java)
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:72)
... 29 more
Caused by: java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(Unknown Source)
at java.net.SocketOutputStream.write(Unknown Source)
at java.io.DataOutputStream.write(Unknown Source)
at net.sourceforge.jtds.jdbc.SharedSocket.sendNetPacket(SharedSocket.java:717)
at net.sourceforge.jtds.jdbc.RequestStream.putPacket(RequestStream.java:570)
at net.sourceforge.jtds.jdbc.RequestStream.flush(RequestStream.java:518)
at net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCore.java:1046)
... 34 more
...
And because that now doesnt clean up properly, the subsequent requests give fail like this
org.hibernate.TransactionException: Already have an associated managed connection
Im not finding it easy to determine which layer is responsible for this problem. From what I have read, the connection pool should test broken connections and clean things up, but I suspect its guice-persist which forever has the broken EntityManager reference associated with its thread-local object. Of course, it may well also be the way Im using them.
EDIT
After further investigation, I noticed that if I wait > 1000ms between each test read, then the code behaves as expected. I get the StackTrace below, and then after I restore the SQLServer service, it happily reconnects. Anything less than 1000ms and I get the error listed above in the original post. It seems hibernate does not handle the IO/Error in the same way and the connection is forever left in a broken state.
javax.persistence.QueryTimeoutException: Could not open connection
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1725)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1771)
at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:64)
at com.google.inject.persist.jpa.JpaLocalTxnInterceptor.invoke(JpaLocalTxnInterceptor.java:66)
at net.impro.portal.server.model.dao.TestConnectionStuff.testConnectionBroken(TestConnectionStuff.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1197)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1122)
at org.testng.TestNG.run(TestNG.java:1030)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
Caused by: org.hibernate.QueryTimeoutException: Could not open connection
at org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert(SQLExceptionTypeDelegate.java:83)
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112)
at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:235)
at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:171)
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:67)
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162)
at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1471)
at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:61)
... 26 more
Caused by: java.sql.SQLTimeoutException: Timeout after 30004ms of waiting for a connection.
at com.zaxxer.hikari.pool.BaseHikariPool.getConnection(BaseHikariPool.java:233)
at com.zaxxer.hikari.pool.BaseHikariPool.getConnection(BaseHikariPool.java:183)
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:93)
at com.zaxxer.hikari.hibernate.HikariConnectionProvider.getConnection(HikariConnectionProvider.java:101)
at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:380)
at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:228)
... 31 more
Caused by: java.sql.SQLException: Network error IOException: Connection refused: connect
at net.sourceforge.jtds.jdbc.JtdsConnection.<init>(JtdsConnection.java:436)
at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:184)
at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:95)
at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:101)
at com.zaxxer.hikari.pool.BaseHikariPool.addConnection(BaseHikariPool.java:444)
at com.zaxxer.hikari.pool.BaseHikariPool$1.run(BaseHikariPool.java:419)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at net.sourceforge.jtds.jdbc.SharedSocket.createSocketForJDBC3(SharedSocket.java:288)
at net.sourceforge.jtds.jdbc.SharedSocket.<init>(SharedSocket.java:251)
at net.sourceforge.jtds.jdbc.JtdsConnection.<init>(JtdsConnection.java:331)
... 10 more
解决方案 I finally found the problem and it is a known hibernate bug with "blocker" status.
Without any reasonable workaround, database recovery seems impossible or at least very impractical.
这篇关于通过休眠恢复破损的数据库连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
