[hibernate-issues] [Hibernate-JIRA] Created: (HHH-6432) ConnectionManager doesn't call closeStatements on AbstractBatcher when release mode is AFTER_TRANSACTION
ConnectionManager doesn't call closeStatements on AbstractBatcher when release mode is
AFTER_TRANSACTION
--------------------------------------------------------------------------------------------------------
Key: HHH-6432
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6432
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.2
Environment: Java 1.6 u25, Win7, Oracle10
Reporter: Shawn Clowater
Priority: Minor
I was running into issues where I was encountering a NPE out of the checkRowCounts of
BatchingBatcher. It was happening when I had an initial session, successfully managed to
batch some entities and then encountered a validation exception causing the transaction to
be rolled back. Upon trying to insert the same type of data in a second session resulted
in the NPE due to the fact that it was still picking up the batched data from the previous
session.
There ended up being a few things in play here.
One of the core snarls was that when using C3P0 it has the ability to cache statements and
that's where it was picking up the old batch from the initial transaction. I fully
think that's a bug on their part and once I knew what to look for stumbled across this
http://sourceforge.net/tracker/?func=detail&aid=3001125&group_id=...
I was able to work around it by implementing my own BatchFactory and on the
closeStatements() and closeStatement() and calling clearBatch() on the statement prior to
closing it.
However, I still needed to call closeStatements() explicitly since the connectionManager
wasn't calling it in my case.
The code in the ConnectionManager in 3.6.2 looks like
{code}
public void afterTransaction() {
if ( isAfterTransactionRelease() ) {
aggressiveRelease();
}
else if ( isAggressiveReleaseNoTransactionCheck() && batcher.hasOpenResources()
) {
log.info( "forcing batcher resource cleanup on transaction completion; forgot to
close ScrollableResults/Iterator?" );
batcher.closeStatements();
aggressiveRelease();
}
else if ( isOnCloseRelease() ) {
// log a message about potential connection leaks
log.debug( "transaction completed on session with on_close connection release
mode; be sure to close the session to release JDBC resources!" );
}
batcher.unsetTransactionTimeout();
}
{code}
You can clearly see that the batcher.closeStatements() isn't called in the first case.
What's even worse is that in the aggressiveRelease() call it nulls out the connection
so even when the Session is physically closed and it calls back to the
ConnectionManager.close() method and ultimately the cleanup() it gets into here and just
returns.
{code}
if ( connection == null ) {
log.trace( "connection already null in cleanup : no action");
return null;
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira