[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-7020) Connection leak with nested sessions
[
https://hibernate.onjira.com/browse/HHH-7020?page=com.atlassian.jira.plug...
]
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