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

Shawn Clowater (JIRA) noreply at atlassian.com
Wed Mar 14 13:14:48 EDT 2012


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

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

The first session is opened without a connection and ends up with the logical connection @ 1640 and the ResourceRegistry @ 1644

When the connection() method is called for the second session it creates another LogicalConnectionImpl when it builds the JdbcCoordinatorImpl when creating the TransactionCoordinatorImpl.  However, we now have nested the LogicalConnectionImpl of the first session as the PhysicalConnection of the second session's LogicalConnectionImpl @ 1702 with it's own ResourceRegistry @ 1708

When the PreparedStatment registers itself when it is prepared it actually calls down through both LogicalConnectionImpls and registers with both ResourceRegistries, when it is released it only gets removed from the second session's ResourceRegistry but is left in an invalid state in the first session's registry.

When the first session tries to close then it hits the invalid registered resource and then blows itself out.  I'll attach a unit test that shows that the first session has registered resources but doesn't actually execute any statements of its own.

> 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-7020Debug.png, 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.

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

       



More information about the hibernate-issues mailing list