aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes BMT Transaction Propagation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "BMT Transaction Propagation" Watch "BMT Transaction Propagation" New topic
Author

BMT Transaction Propagation

Luciano A. Pozzo
Ranch Hand

Joined: Jun 20, 2005
Posts: 112
Hi all,

I have a few questions about BMT transaction propagation of EJB version 2.1. So, first I will explain the situation.


If I have two beans configured as BMT, and the Bean 1 access Bean 2 as below:

BEAN 1 (BMT)



BEAN 2 (BMT)




So, the questions are:
1 - The EJB2 method run in same transaction of EJB1?
2 - Or everytime that I do ut.begin() a new transaction is started?
3 - And, if a new transaction is started, how can I do for run in same transaction of EJB1 (like Required option of CMT)?

Thank's
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

Before begining, I assume you have sound reasons not to use CMTs.

1 - The EJB2 method run in same transaction of EJB1?

In your example - yes. ut.begin() starts a new transaction. The rule with BMT UserTransactions is that it always suspends the incoming transaction and starts a new one with the call to begin(). For stateless, the transaction should finish at the end of the method. This is true irrespective of whether the incoming transaction is BMT or CMT.

2 - Or everytime that I do ut.begin() a new transaction is started?

Yes, see above.

3 - And, if a new transaction is started, how can I do for run in same transaction of EJB1 (like Required option of CMT)?

You should get a handle to the existing transaction, but should not call begin(). Its the begin() that starts the transaction. And since you havent called begin(), you shouldn't commit() or rollback() either from within EJB2.
This is handled by EJB1 which began the transaction. The commit flow is normal and you neednt signal back to the caller that all is well. However if you have an exception in EJB2, you should convey this back to the caller and he would rollback the transaction.

To mark the transaction for rollback, you would call setRollbackOnly() on the UT object from EJB2.

In EJB1, you would check the status of transaction before committing or rolling back. Use the javax.transaction.Status class for checking transaction status.

EJB2



EJB1



I am sure you can tweak EJB2 to mimic the Required behaviour of CMT transactions. Does this help?

cheers,
ram.

[ August 18, 2007: Message edited by: ramprasad madathil ]
[ August 18, 2007: Message edited by: ramprasad madathil ]
Luciano A. Pozzo
Ranch Hand

Joined: Jun 20, 2005
Posts: 112
Hi Ramprasad,

Thank-you for the reply. It was what I wanted to know
Luciano A. Pozzo
Ranch Hand

Joined: Jun 20, 2005
Posts: 112
Ramprasad,

A question about the snippet below (of your code) appeared:



Is it really possibly access the EJB1 transaction status through context.getUserTransaction()? Because according HFEJB (pages 482 and 490):
If you write a BMT bean, nobody else can ever include your bean in their transaction!
.
[ August 19, 2007: Message edited by: Luciano A. Pozzo ]
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

You are right. My pervious reply was incorrect. I am sorry.
The container suspends an incoming transaction (BMT or CMT) when it invokes another BMT - in short a BMT can never take part in another bean's transaction. In stateful session beans, you can have transactions spanning multiple method calls - but it would take a very brave person to do that.

ram.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: BMT Transaction Propagation