Is this a nested transaction?

[Keerthi P]

Scenario - 1:

I have 2 CMT beans, Bean A and Bean B, and:

1. Bean A has methodA()
2. Bean B has methodB()
3. methodA() of Bean A invokes methodB() of Bean B:

         // Bean A method
         public void methodA() {
                beanB.methodB();
                updateTableA();       
         }
 
         // Bean B method
         public void methodB() {
                updateTableB();
         }
  

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:

         // Bean A method
         public void methodA() {
                ut.begin();
                beanB.methodB();
                updateTableA();       
                ut.commit();
         }
 
         // Bean B method
         public void methodB() {
                ut.begin();
                updateTableB();
                ut.commit();
         }
   

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 ]

[alzamabar]

Originally posted by Keerthi P:

My understanding is that Scenario-2 will create nested transaction and the spec does not allow it.

I am not sure about my answer, but I'll give it a go:

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;

2) Because BMT don't accept to run their transaction as part of other callers' transaction context, the normal behaviour will be:

a) methodB will suspend temporarly methodA's transaction
b) methodB will execute its business in its own transaction
c) methodA will continue from where it was suspended

Because methodB has suspended methodA tx, anything happened in methodB tx didn't have any effects on methodA tx, therefore even if methodB rolls-back, methodA will still be free to resume normally.

[Keerthi P]

That makes a lot of sense to me. Thanks Marco.

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 ]

[Eusebio Floriano]

Originally posted by Keerthi P:
That makes a lot of sense to me. Thanks Marco.

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 ]

Same thing for CMT where an required method (A) called an requiredNew method (B). Tx(A) will be suspended until method B ends.

[Lionel Orellana]

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.

Cheers

[Philippe Maquet]

Hi All,

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.

Regards,

Phil.
[ August 26, 2004: Message edited by: Philippe Maquet ]

[Lionel Orellana]

Ye I know EJB only supports flat tx ...

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

[Philippe Maquet]

Hi Lionel,

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.

Regards,

Phil.
[ August 27, 2004: Message edited by: Philippe Maquet ]

[Lionel Orellana]

Hi Phill,

I'm actually talking BMT, scenario 2 in the original post by Keerthi. You got the quote from the spec just there.

All I'm trying to say is scenario 2 is not a nested transaction becuase we have 2 different beans and txs don't propagate between BMT beans. So I agree with what Marco said in his point 2).

But I disagrew with Marco's 1) point.

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;

If methodA and methodB were in the same bean, that would be a nested tx (we're talking BMT, scenario 2). I'm saying the domain for a transaction is not a method but the bean instance.

If it was just one Bean with methodA and methodB, scenario 1 would work but scenario 2 wouldn't. Having two different beans, both scenarios work.

Does that make sense?
[ August 27, 2004: Message edited by: Lionel Orellana ]

[Philippe Maquet]

Hi Lionel,

It totally makes sense. I should/will test it but unfortunately, I've not the time to do it right now.

Regards,

Phil.