jpa - Guice JPA - "This connection has been closed."错误

Question

在 DB 断开空闲连接或 DB 关闭并备份后，我在我的 web 应用程序中收到以下错误:

javax.persistence.PersistenceException: org.hibernate.exception.JDBCConnectionException: could not inspect JDBC autocommit mode
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1365)
    at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1293)
    at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:265)    
... 60 more
Caused by: org.hibernate.exception.JDBCConnectionException: could not inspect JDBC autocommit mode
    at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:131)
    at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
    at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125)
    at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110)
    at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.isAutoCommit(LogicalConnectionImpl.java:395)
    at org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl.afterNonTransactionalQuery(TransactionCoordinatorImpl.java:195)
    at org.hibernate.internal.SessionImpl.afterOperation(SessionImpl.java:565)
    at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1220)
    at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101)
    at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:256)
... 70 more
Caused by: org.postgresql.util.PSQLException: This connection has been closed.
    at org.postgresql.jdbc2.AbstractJdbc2Connection.checkClosed(AbstractJdbc2Connection.java:712)
    at org.postgresql.jdbc2.AbstractJdbc2Connection.getAutoCommit(AbstractJdbc2Connection.java:678)
    at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:126)
    at org.apache.tomcat.jdbc.pool.JdbcInterceptor.invoke(JdbcInterceptor.java:99)
    at org.apache.tomcat.jdbc.pool.DisposableConnectionFacade.invoke(DisposableConnectionFacade.java:63)
    at $Proxy66.getAutoCommit(Unknown Source)
    at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.isAutoCommit(LogicalConnectionImpl.java:392)

当这开始时，我得到一个

SQL Error: 0, SQLState: 08006 - An I/O error occured while sending to the backend.

但在那之后它只是:

SQL Error: 0, SQLState: 08003 - This connection has been closed.

问题是:我已经设置了 testOnBorrow，所以我希望只获得开放的连接。

如果这有帮助:通常池中包含好的和坏的连接，随着时间的推移，问题似乎会消失，但我让服务器运行了 12 小时以上，但仍然返回了坏连接。
重启后一切正常(一段时间)。

我已经对这个问题进行了更多的调试，似乎池正在返回错误的连接，例如如果在数据库上杀死所有连接后，我得到:

SQL Error: 0, SQLState: 57P01

然后是通常的东西 - 从池中返回被杀死的连接。
问题是:是应用程序问题吗？

我尝试通过 JMX 清除池，但这似乎没有任何效果。
另一个奇怪的事情是，即使应用程序显然没有做任何事情(通过线程转储检查)，JMX bean 显示 7 个事件连接和 0 个空闲连接。当我执行需要访问数据库的请求时，我立即得到响应(尽管没有可用的空闲连接)，但之后 JMX 显示 7 个事件连接和 0 个空闲连接。

附注。也许我遗漏了一些明显的东西，这是我的连接管理问题？我正在使用通过 persistence.xml 配置的 JPA EntityManager，所以也许我做错了什么并且连接在使用后没有正确关闭(返回)？

Answer 1

实际上，当我怀疑应用程序错误时，我是对的。
这一切都在 Issue 730: Automatically started UnitOfWork is never ended 中得到了很好的描述

When using the JpaPersistService, if you attempt to access an EntityManager outside of an active UnitOfWork, Guice will automatically start one for you. However, as Guice does not (and cannot) know when to end this UnitOfWork, it never does.

Result? The offending thread will be stuck with the same EntityManager throughout the life of the application. This is a bad state for the application to run in, and ours inevitably exhaust the available memory after a while and crash.

The real killer here is that it's not at all obvious when you've made this mistake. The only real tip-off is that you're getting inconsistent data from your database between different threads (due to the EMs first-level cache) or that the applications memory consumption keeps on growing. In my case it was the active connection in the pool that got me to suspect it, and then, when I turned on detailed logging I noticed that app was not borrowing the connection from pool at all, instead it was reusing the connection already held by unclosed EntityManager.

实际上，报告的此问题有相当多的重复项: http://code.google.com/p/google-guice/issues/list?can=1&q=UnitOfWork