christian wrote:
Yeah, blame me, good idea.
I wasn't blaming you. I was responding to your comment that I "don't spend much time looking for solutions".
christian wrote:
Here is a copy and paste again from the very same page: "If you like you can add a catch(RuntimeException) clause and handle it in the HibernateFilter, or you can write a more generic error handling filter for your whole application."
Ok, maybe I'm missing something since you see this as being very obvious but I read this, based on where it is in that page, as suggesting a catch in the doFilter method. By the time you are there you don't know if an exception was thrown.
If that phrase is suggesting storing a boolean value in thread local storage and then use that boolean to perform a commit or rollback, then yes that would work - but I think it would be much cleaner in the catch to rollback and close the session then.
christian wrote:
Here is another copy/paste from the Hibernate documentation: "If the Session throws an exception (including any SQLException), you should immediately rollback the database transaction, call Session.close() and discard the Session instance. Certain methods of Session will not leave the session in a consistent state. No exception thrown by Hibernate can be treated as recoverable. Ensure that the Session will be closed by calling close() in a finally block."
Exception handling is not in the scope of Hibernate, it's totally dependent on the rest of your application design. Yes, you might have to bring 2 and 2 together yourself to make it work correctly. But, from now on you can do that without my help.
Yep read that. That is one of the reasons I asked this question. Many places in the book it did cover rollback in a way that made a lot of sense. But then chapter 8 which I view as basically a "best practices" then doesn't handle rollback. That is what has lead to my basic question on this - why does chapter 8 not address rollback when it is telling you how you "should" implement hibernate?
- dave