[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2604?page=c...
]
Diego Plentz commented on HHH-2604:
-----------------------------------
The current finally block looks like this:
finally {
if ( transacted && wasAutoCommit ) {
try {
connection.setAutoCommit( true );
}
catch( Throwable ignore ) {
log.trace( "was unable to reset connection back to auto-commit" );
}
}
session.getBatcher().closeConnection( connection );
}
So, the problem is that AbstractBatcher.closeConnection method does not verify if
connection is null (then NPE...). I thinking if is better to check at closeConnection
method or before calling the method in the finally block.
Isolator.JdbcDelegate masks the exception if it isn't possible to
open a connection.
------------------------------------------------------------------------------------
Key: HHH-2604
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2604
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.4
Environment: Hibernate 3.2.2ga
Reporter: Tushar Pokle
Priority: Minor
A defect in Isolator.JdbcDelegate makes it throw the wrong exception - a
NullPointerException - that masks the true exception. In my case it was an
UnsupportedOperationException("The user must supply a JDBC connection").
The trouble is at the start of Isolator.JdbcDelegate.delegateWork(...):
{code}
174 public void delegateWork(IsolatedWork work, boolean transacted) throws
HibernateException {
175 Connection connection = null;
176 boolean wasAutoCommit = false;
177 try {
178 connection = session.getBatcher().openConnection();
{code}
If there is a failure opening a connection on line 178, the finally clause is executed.
The finally clause needs the connection, which of course is null :-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira