1. Bean A has methodA() 2. Bean B has methodB() 3. methodA() of Bean A invokes methodB() of Bean B:
4. The transaction attribute of methodA() is REQUIRED and that of methodB() is REQUIRES_NEW. (I want to update Table A no matter Table B updation succeeded or failed)
I understand that the above code is perfectly valid and runs predictably.
Scenario - 2:
If I want to achieve the same effect for BMT beans, I will have methods coded as follows:
My understanding is that Scenario-2 will create nested transaction and the spec does not allow it. If that is case, how can one justify that Scenario-1 is valid? Is scenario one really a nested transaction? Can someone please clarify? [ August 11, 2004: Message edited by: Keerthi P ]
A nested transaction occurs when a new transaction is started on a session that is already inside the scope of an existing transaction. The new, nested transaction is said to be nested within (or below the level of) the existing transaction. Changes made within the nested transaction are invisible to the top-level transaction until the nested transaction is committed. Even then, the changes are not visible outside the top-level transaction until that transaction is committed.
In case of the BMT scenario above, the existing transaction will be suspended and a new transaction is started when methodB() runs. So this is not a nested transaction. [ August 11, 2004: Message edited by: Keerthi P ]
1) The domain for a transaction is a method, therefore unless in the same method you have more that one ut.begin() we cannot speak nested transactions;
So what happens if methodA and methodB were in the same bean? I think in that case it would be a nested transaction. What really matters here is that we have two different beans, not two different methods.
EJB does *not* support nested transactions (exactly as JTA BTW), only "flat" ones.
Even when a method A with a "required" transaction attribute, calls a method B which has a "requiresNew" transaction attribute, the corresponding transactions are *not* "nested" because they keep independant from one another.
The first one is suspended till the second one completes, and however the second completes (commit or rollback), the first one comes back to life, independently.
Nested transactions are different: the outermost transaction keeps control on its child transactions. For instance, if the child transaction commits but its parent finally issues a rollback, the whole transaction (child included) rollsback.
Phil. [ August 26, 2004: Message edited by: Philippe Maquet ]
That's why I'm saying if methodA and methodB were in the same bean (please read the original question), that would be a nested transaction and the container will complain ...
I'm not sure you're right (we were talking about CMTs, right?). Could you please give us a reference to the specs? Thank you in advance.
As far as BMTs are concerned it looks different though:
BMT last paragraph of section 17.6.1, pg 357. When an instance attempts to start a transaction using the begin() method of the javax.transaction. UserTransaction interface while the instance has not committed the previous transaction, the Container must throw the javax.transaction.NotSupportedException in the begin() method.
Phil. [ August 27, 2004: Message edited by: Philippe Maquet ]