Hi;

In HiA page 304 it shows how to use doFilter to commit and close a session. And all the associated code then shows no try/catch for hibernate exceptions.

But unless I'm missing something, if a hibernate call throws an exception (say an update on a record that is no longer in the DB), don't you need to catch it and then call rollback in the exception handler?

??? - thanks - dave

You don't spend much time looking for solutions... Instead of giving you another copy/paste of the book to reread, here is a slightly different explanation: http://www.hibernate.org/43.html

After I first looked at hibernate I emailed a bunch of friends of mine asking for their opinion. And while it was 100% positive, 3 of them said that the experts on the support forum were totally intolerant of anyone who did not know as much as them asking questions.

I've read the book - I think 3 times now with all the re-reads. I've been through the test sources and the caveta emptor ones - mostly using grep to find appropiate examples.

I just read the link you pointed me to. And in all of that, I don't see anything in the "suggested" approach where the Session.close() is held off to the end of a servlet request, where an exception leads to a rollback. It looks like an exception is basically ignored and the operations that did succeed are committed.

But please, since you clearly think I didn't spend much time looking for a solution - where in the link you gave me does it discuss rollback? I finally did a text search and the word rollback is not even on that page.

- dave

Yeah, blame me, good idea.

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."

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.

I wasn't blaming you. I was responding to your comment that I "don't spend much time looking for solutions".


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.


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

You joined this forum 3 days ago. You already opened 8 threads, which, as far as I know, is a new record. All of your questions have been answered almost immediately, including your many follow up questions. Now you are telling someone who is helping you on a Sunday that he is "intolerant", and to make it a little bit more insulting, you cite some imaginary friends.

Before the credit system you would have been banned by now. My friendly advice: rethink your strategy how to behave on a public forum and how to treat people who give you free help and free software.

"By the time you are there you don't know if an exception was thrown."

And... another point of advice: learn how exceptions work in Java before you start arguing with someone.

[quote="christianYou joined this forum 3 days ago. You already opened 8 threads, which, as far as I know, is a new record. All of your questions have been answered almost immediately, including your many follow up questions.[/quote]

I'm not going to discuss this issue with you as this has turned in to a pissing match. I am hoping that someone else will address why Chapter 8 in HIA does not suggest catching an exception and performing a rollback on it.

As to my 8 posts - 2 were informational posts to try and help others, not questions. (This was before I realized the point system penalized a person for posting help/suggestions as a new post.) And FWIW if not for the point system, there are 3 additional posts I would have made of things I learned so others would find them in a search.

As to drilling down and finding out why on things like int vs Integer or why cascade='all' is only in some examples of 1:many, I prefer to figure out to the last detail what is going on rather than making assumptions and ending up with code that is buggy or at a minimum, sub-optimal.

And when I see differences in the docs/book in how it suggests coding something, I figure it's better to ask than to just pick one and continue. And when the documentation is not consistent - there is no way to find the "correct" solution than to ask.

- dave

In fact, this is all discussed, and solutions are provided in the code listings of chapter 8. Take a look at HibernateUtil.commitTransaction().

It'd be great if you had a direct line into the devs' brains so every time you had the slightest doubt about anything, you could triple check and so attain that warm, fuzzy feeling of complete certainty. Unfortunately, it doesn't work that way. You're expected to be able to discover, infer, and deduce solutions to a large majority of the problems you encounter during day to day development, and only actually ask questions about the in-depth, complicated stuff you can't figure out yourself. Why cascade=all appears on only some one-to-many relationships, or why you should use int or Integer are not grand mysteries but simple documented facts that you're either too lazy to look up or too emotionally fragile to implement without constant affirmation.