[hibernate-issues] [Hibernate-JIRA] Updated: (HHH-7020) Connection leak with nested sessions

Connection leak with nested sessions ------------------------------------ Key: HHH-7020 URL: https://hibernate.onjira.com/browse/HHH-7020 Project: Hibernate ORM Issue Type: Bug Components: core, entity-manager Affects Versions: 4.0.0.Final, 4.0.1, 4.1.0 Environment: Windows 7. Java 1.6.0_25, Java 1.7.0 Reporter: Zoltán Holub Attachments: HHH-7020.diff, testcase-connectionleak.zip I'am using a Hibernate interceptor to track data modifications. In the interceptor's onFlushDirty() method, i open a new session without interceptors using the same JDBC connection. After closing this nested session and the original entitymanager, the JDBC connection doesn't released. I could reproduce this problem outside any interceptor. I have made a junit test without interceptors which shows the same problem. I have found that Hibernate throws and catches a HibernateException with message "proxy handle is no longer valid". This exception is logged on debug level. I investigated that the problem is in the following code: LogicalConnectionImpl.java public Connection close() { LOG.trace( "Closing logical connection" ); Connection c = isUserSuppliedConnection ? physicalConnection : null; try { releaseProxies(); jdbcResourceRegistry.close(); if ( !isUserSuppliedConnection && physicalConnection != null ) { releaseConnection(); } return c; } finally { // no matter what physicalConnection = null; isClosed = true; LOG.trace( "Logical connection closed" ); for ( ConnectionObserver observer : observers ) { observer.logicalConnectionClosed(); } observers.clear(); } } The invocation of jdbcResourceRegistry.close() throws this exception, and this is why it skips the following releaseConnection(). The condition of IF statement is true. This code is new to Hibernate 4. I have tried 4.0.0, 4.0.1 and 4.1.0-SNAPSHOT and all of them has the problem. Hibernate 3.6.0 is not affected. My JUnit test could run with Hibernate 3.x with minor changes. (3.x code also in the JUnit test) I have tried different ways to work around the problem. The only way it worked is to use a simple doWork() and native JDBC operations. This test case also in the unit test.