EJB 3.0 - Nested Transaction != Requires New?

Question

I just read the Transactions Chapter (10) of "Mastering EJB 3.0" and now I'm confused about nested transactions.

The book says

"The EJB-defined transaction manager does not support nested transactions; it requires support for only flat transactions." (Site 278, Note)

This fact is described not only by this book, I found this statement in other books / websites.

But if I call a "Requires New" annotated Method from a, let's say "Required" annotated Methode, what I have is a nested transaction, isn't it? I can roll back the inner transaction or commit it, without affecting the outer transaction. And if I want the outer Transaction to be aborted, I throw an EJBException back and the whole transaction will be rolled back.

So is it just that this behavior is not required by the EJB 3.0 specification or have i misunderstood something? I just can't get the difference between nested transactions and the described behavior.

Regards Norman

Dialectician

"Inner" and "outer" implies that if we commit the inner and then rollback the outer, then the inner is somehow rolled back too even though it was already committed, but EJB does not support this behaviour: all transactions are committed and rolled-back independently of one another. – Elwin

Answer 1

RequiresNew does not create a nested transaction because the first transaction is suspended while the second transaction is running. A nested transaction looks like this:

Nested transaction example
> method1 - begin tran1
  > method2 - begin tran2
    workA
  < method2 - commit tran2
< method1 - rollback tran1 (tran2 also rolled back because it's nested)

Instead, RequiresNew looks like this:

EJB RequiresNew example
> method1 - begin tran1
  > method2 - suspend tran1, begin tran2
    workA
  < method2 - commit tran2, resume tran1
< method1 - rollback tran1 (tran2 remains committed)

Piggish

Thanks for this answer, now it becomes clear to me :) but if I use mandatoy or required for the inner transaction, it behaves like a nested transaction although it belongs to the outer transaction, right? – Dialectician

If you use mandatory or required, then the container does nothing for the inner method. There's no "inner"/"outer" transaction distinction, the container just leaves the transaction alone. – Piggish

So what is the proper term for this "RequiresNew" transaction type? Is it nested top-level transaction like described here publib.boulder.ibm.com/infocenter/txformp/v5r1/… ? – Kerchief

Yes, the EJB RequiresNew is the same as "nested top-level transaction" described in that document. EE has nothing that is the same as "nested subtransaction" described in that document. – Piggish

@bkal: So practically what is the difference between a nested transaction and a required transaction? In both cases if the nested (or required) transaction rolls back then also the outer (the whole) transaction will roll back which is the same. – Moon

@MikeArgyriou No, for non-nested (JTA) transactions, the two transactions are completely independent: the commit/rollback of one transaction has no effect on the other. – Piggish

@bkail: According to docs.oracle.com/javaee/6/tutorial/doc/bncij.html#bncim and REQUIRED attribute: "If the client is running within a transaction and invokes the enterprise bean’s method, the method executes within the client’s transaction.". Therefore if the method rolls back also the client's transaction will roll back. Isn't this behavior similar to nested transactions? – Moon

@MikeArgyriou No, in that scenario, the enterprise bean method reuses the existing transaction of the client, it does not begin a new transaction (nested or otherwise). At this point, you should probably open a new question rather than asking questions on this old answer. – Piggish

Answer 2

Simple answer is the "outer" transaction is suspended before the new transaction is started. The fates of the two transactions are not in any way linked, so by all intents and purposes one is not nested into another.

If the REQUIRES_NEW method throws an EJBException it is the new transaction it created that will be rolled back, not the "outer" transaction.

Infuriate