I am frustrated by this:

try { doSomethingWithHibernate(); threadLocalSession.close(); }
catch (HibernateException ex) {
// now I just want to deal with the exception... but I still have to close the session!
try { threadLocalSession.close(); } catch (HibernateException) { /* ignore it! */ }
}

In other words, when something goes wrong, Hibernate still wants you to close the session. I would like to do that in my catch clause. But because session.close ALSO throws HibernateException, I have to write ANOTHER catch clause, and it's not clear what I can *do* with the session's failure to close!

So why does session.close() throw an exception, what should I do if it does, and what is the best pattern for closing sessions in catch or finally clauses?

Cheers!
Rob

Session.close() throws an exception because it calls JDBC Connection.close()

You are a god among men, Gavin, and I am a huge fan.

That said, is this the right pattern to use? (taken from one of our SLSB's, aka our service layer):

public void deleteList (Long sourceListId) throws NFNoSuchEntityException {
try {
BeanAssetManager.deleteList(sourceListId);
} catch (HibernateException e) {
throw new NFInternalErrorException("Could not delete list with id "+sourceListId, e);
} finally {
try { Persistence.closeSession(); } catch (HibernateException ex) {}
}
}

Seems to me this closes the session regardless of what exceptions could fly out of the service layer. Previously I had the closeSession inside the try (rather than in the finally), and I have verified that that results in errors like this if NFNoSuchEntityException is thrown:

2004-01-29 15:52:19,410 : Pool.freeConnections : WARNING: Connection not closed by caller
2004-01-29 15:52:19,473 : XAResourceImpl.end : END without START or mixed xids: 3e9903073c470_0_3e9903073c470_0_ != null
2004-01-29 15:52:19,473 : Pool.closeConnection : Pool: Exception while delisting resource:javax.transaction.SystemException: Cannot send XA end:javax.transaction.xa.XAException

This doesn't seem good.

My original question does remain, though: what is a caller expected to *do* if session.close() throws an exception? This might be a question for JDBC itself, but still... what do *you* do in this situation, Gavin?

Thanks again for Hibernate!
Cheers,
Rob

Ay, stop that, I gotta big enuff ego as it is....


I would probably wrap it in my InfrastructureException and report a generic failure to the user.

But I think its probably reasonable to just log a WARN and continue, if and only if you know that the transaction was successful (looks like you don't in your case).

Personally, I always centralize all exception handling in my systems - which is a lot harder with the session facade pattern, since the stupid EJB spec doesn't provide interceptors. Thats one reason why I use command pattern instead of session facade (I can have my own interceptor fwk).

Hm. So you're saying that session.close() could throw an exception if the transaction itself fails?

But session.close() doesn't mean the container has committed the transaction, does it? It just finalizes the session itself. The transaction could still fail after my session bean has entirely returned (and after session.close() has completed successfully). Right?

Or is it the case that if the transaction is going to fail, session.close() is *when* it will fail?

Would doing a session.flush() inside the try{} block cause any transaction failures to happen there rather than inside session.close(), or are there failures that could happen only inside session.close()?

Thanks again,
Rob

Exactly, this is always possible. Thats why your code is probably not quite safe.

(I am really sorry to reply to you so much, and I really appreciate your helping me dig to the bottom of this. This is one of those times where if we were in the same room you could have explained it to me in 30 seconds, but the round-trip latency and limited text bandwidth is killing our performance ;-)

But how *could* my code be safe in that case? What you're saying is that even if I do:

try { someHibernateThing(); }
catch (HibernateException ex) { throw MyInfrastructureException(ex); }
finally {
try { ThreadLocalSession.close(); } catch (HibernateException ex) { throw MyInfrastructureException(ex); }
}

...and someHibernateThing() *doesn't* throw any exceptions, and the finally block *doesn't* throw any exceptions, and the Hibernate session is happily closed, and I didn't throw any MyInfrastructureExceptions...

... the transaction could *still* fail when the container goes to commit the transaction, and who knows *what* the container will do (probably throw *its* MyInfrastructureException?!).

In other words, it looks to me like if the container is responsible for the commit, and if the commit can fail after my code has completely finished executing and all Hibernate sessions are closed, then there *is nothing I can do* to be more safe in that situation.

So I don't understand why you say "Exactly, that's why your code is not quite safe," when in the scenario I was describing, there's nothing my code *can* do to *be* more safe!

Or did I just miss your point, and are you approaching exasperation with my denseness? ;-)
Cheers!
Rob

(p.s. when's that book gonna be done? I'll be reviewing chapter 6 this weekend...)

The book will be in print second quarter 2004, but we hope to have some chapters earlier on the Manning Early Access Program.

The code you have just shown that throws a MyInfrastructureException is safe. The previous version, which swallowed the exception, is a little bit less safe.

Okey dokey :-) I'll stick with that pattern then. Thanks!
Cheers!
Rob