I am reading conflicting things about using Hibernate 3 and nested transactions in relation to the default transaction manager. If I have setup a datasource in JBoss that uses the default transaction manager (and it appears to default to the org.hibernate.transaction.JTATransactionFactory) nested transactions do not work for me. This is what I see:



If I remove the nesting, then the error goes away. The code looks something like this



Now, I WANT the nested transaction to work. If the inner fails (method2) then the outer (method1) should fail as well.

This does not work at all. The only way it works is if I remove the session.beginTransaction() in method1 and therefore remove the nesting.

So I have two questions:

1.) Can I do nested transactions with the default JTA transaction manager.
2.) If not, which transaction manager can I use that will allow me to do this?

Thanks in advance,
Mark

In this case, you don't want nested transactions. The whole point of a nested transaction is that if a nested part fails, the higher-level transaction doesn't. The nested part rolls back cleanly, leaving the higher level transaction back where it was before the nesting started.

To implement what you need, use only a top-level transaction. If anything causes it to roll back, everything is rolled back. This is what you need.

If you need to put a beginTransaction in all your methods, then you should wrap session.beginTransaction with your own method that includes either reference counting (so you only commit after the first transaction is committed) or intelligently ignores begins/commits that aren't "top level". Obviously rollbacks should always work.

Are you saying that nested transactions in hibernate equate to tx suspension? In pure SQL nested tx functions like markricard desires. The way you've written it, it seems that hibernate suspends the intial tx and completes a completely independent atomic unit of work before continuing to commit the initial tx.

Hibernate uses plain vanilla SQL transactions, unless you tell it to use a more complex transaction manager (JTA, etc.. I believe you get this automatically when working with JBoss). I guess nested transactions work differently on different DBMSs? I call what you've described "named transactions", and as far as I'm aware, hibernate does not support them. Hibernate seems to work with just one transaction per connection (happy to be corrected on that).

What I wrote before didn't say that hibernate suspends transactions, merely that you don't want to use (what I'm calling) nested transactions: rather that you want to use named transactions. Perhaps my terminology is wrong, but that's what I meant. Afaik, hibernate doesn't support either system "out of the box", but can be easily tweaked to handle what you're looking for. You don't even have to go as far as extending the transaction manager: simply maintaining a count of the number of times "beginTransaction" has been called will give you all the power you need.

As tenwit has said Hibernate uses the underlying Transaction manager. So behaviour depends on the TxManager and your configuration, in general this means that you will get a suspended transaction which gets resumed once the 'nested/sub' transaction completes its cycle.

True enough. I should have specified that MS SQL allows nested txs that participate in the outer tx and rollback if any tx fails. I still see this as an issue with hibernate as you can easily have multiple "service" objects that call other service objects and expect any tx initiated in one propagate to the others. JBoss' persistence seems to do this, which strikes me as unusual since it is hibernate, no? All transactional method calls propagate their txs (if annotated as such). Why can't hibernate do this alone?

No, JBoss transactions are JTA, and that's container-managed. JBoss is aware of lots of transactions and can act as a transaction administrator. Hibernate "default" transactions are JDBC, and they're API-controlled.

Good answers. Then a container like JBoss or Spring is required in such cases. Good to know. Thanks.