aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Is this a nested transaction? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Is this a nested transaction?" Watch "Is this a nested transaction?" New topic
Author

Is this a nested transaction?

Keerthi P
Ranch Hand

Joined: Aug 19, 2003
Posts: 203
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:

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 ]

Cheers.<br />Keerthi<br />(SCJP, SCWCD, SCBCD)
alzamabar
Ranch Hand

Joined: Jul 24, 2002
Posts: 379
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.


Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD
Keerthi P
Ranch Hand

Joined: Aug 19, 2003
Posts: 203
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
Ranch Hand

Joined: Mar 07, 2004
Posts: 235
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.


SCJP 1.4 / 5.0 - SCBCD 1.3 - SCWCD 1.4 - IBM 484
Lionel Orellana
Ranch Hand

Joined: Mar 19, 2004
Posts: 87

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
Bartender

Joined: Jun 02, 2003
Posts: 1872
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
Ranch Hand

Joined: Mar 19, 2004
Posts: 87
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
Bartender

Joined: Jun 02, 2003
Posts: 1872
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
Ranch Hand

Joined: Mar 19, 2004
Posts: 87
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
Bartender

Joined: Jun 02, 2003
Posts: 1872
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Is this a nested transaction?
 
Similar Threads
BMP transaction propagation v nested transaction
try..catch block
Synchronization on Threads in Java
Are UserTransactions propogated into other methods?
BMT Transaction Propagation