I am using client demarcation and calling two methods on a stateless session bean for example (withdraw & deposit). It doesn't work. There is no impact of the rollback done at the client. Can any one shower some light in this regard

Thanks
venkatesh

What are the transactional attributes that you have set on the bean(s)? I assume that your SLSB's are a facade to the CMP/BMP entity beans actually making the transactions at the database level?

GJB

PS: For a good discussion on this/similar issues with transactional attributes, take a look at Chapter 10 & 14 from Ed Roman's book Mastering EJB1, available from this site.

I am not using any entity beans. My session bean methods just uses tx datasource to get a connection and does the database operations. I have used TX_BEAN_MANAGED. For examples

Client
step 1 . getUserTransaction through lookup
step 2 . ut.begin();
step 3 . Bean.withdraw();
step 4 . Bean.deposit();
step 5 . ut.commit();
step 6 . Any Exception ut.rollback();

There is difference between a transactions at bean level and transactions at database level.
Whatever database transaction you have made is already commited. so the user or the container will not be able to make the rollback by itself.
Instead you can create a connection with autocommit set to false. Use the same connection object as reference to do all your transactions. Finally if all the transaction goes fine then before doing the ut.commit in your code, do the database commit.
incase of ut.rollback do the connection.rollback.

this will take care of your rollback operations in database level.

All the best

Make sure you're using a Transaction Datasource and set your autocommit to false. Contrary to what Suresh Rangan has claimed, I believe you do not need to pass your Connection reference objects around. Under the "umbrella" of a transaction demarcated by your client, your single bean/multiple beans access will use the same Connection reference automatically until your client commits/rolls back.

Hi Chng, i think u got me wrong. what i was trying to say was when different object doing different database updates and if the business needs everything under a single umbrella then its very essential that all the object should use the same database connection objects.

Especially when we are using Weblogic or any connection pool. we need to keep the resource till we are done with that particular transaction.

i had the same problem and i solved it this way and now it works fine.

Regards
Suresh

<SURESH> Finally if all the transaction goes fine then before doing the ut.commit in your code, do the database commit.
incase of ut.rollback do the connection.rollback.

this will take care of your rollback operations in database level.
</SURESH>

I am still not convinced that you have to issue database commit or rollback explicitly. I thought the whole point was to let the EJB container manage transacations on your behalf. As long as all the objects (EJBs) involved are using the same connection pool, you don't have to worry about explicitly managing trasactions at the database level.

Thats true Rafiq, but only when you are using Container Managed Persistence. when u use transactions from SessionBean-JDBC level or BMP level we need to explicitly take care of the database transaction.