Hi,
I have requirement like this.
Bean A and B are stateless session beans.
They get independent database connection from connection pool.
Both bean insert rows in database through Data Access Objects.
I want to call Bean B from Bean A, but both should be in same transaction, i.e. insertion of bean A and B should in a transaction. But bean A and B have different JDBC connection objects.

I guess this problem can be solved using JTA, but I do not have the details.
Thanks,
Badrish

This should not be an issue. So as long as you are not trying to lookup any information persisted in Bean A from the DB in bean B.

Can you explain. I'm not cleat about it.

When bean A is calling bean B, pass the connection object as an argument.
Let b use the same object and commit and rollback in its method.

First off the suggestion recomended will work only if bean b is accessed via a local interface.

The idea is that Bean A and Bean B participate within the same constianer transaction. Bean A get a DB Connection from the pool and so does Bean B. When Bean A performs DML operations using the connection all the operations are vlaid within the scope of that connection until the containers transaction is commited. Assuming you are using the connection with AutoCommit turned off. Now if this where the case and you tried to access the information from bean 2 the data would not be available to it since it has still not been committed.

Hope this helps.

Yes u need to use JTA - ditributed transactions, which can either be done through bean managed (programmatic) or container managed transaction.

if its container-managed then u jus need to play around with the deployment descriptors, essentially set the following properties, for beana.method - New Transaction and for beanb.method - RequiresTransaction or even supportstransaction would work. so if theres an exception the container will roll-back the transaction, but in case u want more control on a roll-back, u can use ejbcontext.setRollBack

make sure that u fetch the connection to the database from the datasource, coz this ensures that resource gets enlisted in the transaction. this holds true for both CMT and BMT.

in case u wanna do bean-managed, u need to put couple of lines of code. get the usertransaction object from the current ejbcontext, before u get the connection from datasource.

UserTransction trans = ejbContext.getUserTransaction();

// get connection from datasouurce
// DML statements against the connection

trans.commit() or trans.rollback()

U would do the same in both bean a and bean b

hope this helps.

Other than the one statement that I do not understand very clearly, your process should be a very simple one, where both beans should use 'Transaction Required' as the attribute in the xml descriptor file. When an updateable method in A is called, a transaction will be started by container (if you chose to do container managed, which I recommend).

When an updateable method in B is called by A's method, the same transaction will be used. To be more clear, if and when you did getConneciton form B's method, the conneciton obtained will be the one that has already served bean A.

What I do not understand in your question is the statement about 'independent database connections from a pool'. Container managed transactions ensure that the same connection is obtained everytime a getConnection is called once a transaction has been started.

Also, in one or more of the other replies, I kind of see that there is doubt about visibility of persisted data between A and B. Since both beans are in the same transaction, persisted data will be visible across the 2 beans even before a commit because it is the same connection that is being used.

Also, since I am assuming you will be using Container Managed Tranactions, please do not perform your own commit/rollbacks etc.

Hope this helps
Ashar

You are correct. The other replies are going down the wrong path. Use "transaction required" on methods in both session beans and the same transaction will be used for container managed transactions. That is the whole point of container managed transactions.

John H.