[hibernate-issues] [Hibernate-JIRA] Created: (HHH-6432) ConnectionManager doesn't call closeStatements on AbstractBatcher when release mode is AFTER_TRANSACTION

[Shawn Clowater (JIRA)]

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=25357&atid=383690

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