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

[Shawn Clowater (JIRA)]

    [ https://hibernate.onjira.com/browse/HHH-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45973#comment-45973 ] 

Shawn Clowater commented on HHH-7020:
-------------------------------------

Steve, I think if it were the same JdbcResourceRegistry then the test would actually pass since when the second session finishes executing the statement it would invalidate and remove it from the shared resource registry so the first session would no longer have any registered resources and would be able to close.

I think handling the close so that it doesn't fail the connection release is probably worthwhile nonetheless.

I'm not sure you can share the same LogicalConnection if you aren't sharing the TransactionContext can you?  i.e. if the 2nd session were to start a nested transaction and commit it, then it calls cleanup on the JdbcResourceRegistry which would clear anything that the first session might have registered.

I think you're ok as long as when you build the second session you unwrap the proxy before it's passed as the user supplied connection.  (or why not the physical connection?)

You'll actually run into this same sort of issue (i think) anytime a proxied LogicalConnectionImpl is passed into another one since to do something like call prepareStatment() goes through the proxy and registers the resource at the multiple levels.

> 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
>            Assignee: Steve Ebersole
>         Attachments: HHH-7020Debug.png, HHH-7020.diff, HHH-7020-TestCaseNoSpring.zip, testcase-connectionleak.zip
>
>          Time Spent: 1.1h
>
> 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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira