I'm using Hibernate 2.1 with MySQL with InnoDB tables (though I've seen the same behavior with Oracle 8.x). The problem I'm having is with transactions not rolling back. My Servlet Engine is Tomcat 4.

in hibernate.cfg.xml I've set:



My java code looks like:



I've stepped through the code, and when there is an error on the flush, I verify that rollback is being called. However, the data from associations is not getting rolled back. I am sure of this because I start my test with an empty DB.

I've tried taking the flush out, still no roll back.

If I add 'session.connection().setAutoCommit(false);' before the call to beginTransaction, I get very strange behavior. I step through the code, and my newly created object has it's id set inside the saveOrUpdate, but, on flush (or commit if I take the explicit flush out), I get an error saying that the object already exists. Huh? However, the rollback does work in this case.

How can I have both rollback capability and be able to saveUpdate newly created objects? I know this is wanting to have my cake and eat it to, but it is rather important ;)

You're transaction logic looks a bit odd. I believe the standard(ish) pattern for exception handling is this...



Try refactoring your code to see if this helps.

Thanks, but that's definitely not the problem here. My code isn't really any different, just more robust.

The differences are:

1) I catch Throwable as opposed to HibernateException. This ensures that I call my convertException (just some boilerplate error logging code that will rethrow an appropriate exception) even if a RuntimeException or Error occurs.

2) I put the rollback in the finally clause to make sure that it gets rolledback regardless of error condition. By placing the rollback in a catch (HibernateException) clause, there is danger of hanging transactions out to dry on any uncaught exception (RuntimeExceptions and Errors can be thrown regardless of what's declared).

3) Having the rollback in the finally clause forces me to check if the transaction was commited because, at that point, I don't know whether an exception/error was thrown.

You're right that the example you quote is the standard way you see that stuff written up in the documentation and tutorials. But, remember, those examples are trying to get illustrate a point and industrial error handling isn't a big concern. I would recommend you go through all your code and alter it to something similar to mine if you are doing anything for a production app.

If you have only one method in application then this code must look like this:




If you have more than one method or you are going to have more methods then your code must look like this:

Two things I'd suggest. Put debug logging on in hibernate and post that, and that the autocommit mode, of your connection before you start a transaction tho that shouldn't matter as hibernate will set it to false regardless.

I don't understand why you are calling flush. I believe trx.commit() is sufficient, and that flush is only if you dont use a transaction.

Thanks for the responses. I found the problem, and it wasn't the flush or commit. Turned out to be a problem due to the odd way I was forced to map the associations (see an earlier post). The error 's stack trace was just misleading. Fixed the problem by adding an artificial Entity to track an id, key and value.

baliukas, I really don't understand what you were trying to say. You might want to read what I posted just before your own post. What you recommend is only okay if you don't care about leaking transactions.

Myk, You win the golden suggestion award. I hadn't read it until afterwards, but, it was checking out the hibernate debug output that lead me to the problem.

hbendelbo, the flush might be redundant, but, it certainly doesn't hurt, and I've been burnt one too many times relying on code to do things like this implicitly.