rollback() and setRollbackOnly()

[Vipin Mohan]

hi friends
I'm not clear about why we need the setRollbackOnly() method when we have the rollback() method for BMT beans. I read that rollback() is placed at the end of the transactional code if you want to end it without a commit and setRollbackOnly() is called earlier in code if you can make out that the transaction is not going to succeed. My question is why do I need to call setRollbackOnly() itself to inform other participants in the transaction ? Why can't I call a rollback() itself to inform them ? Is there any particular advantage of calling setRollbackOnly() ?
Thanks
Vipin

[Ashish Pagare]

I believe you are confused with usability of the two methods.
1. javax.ejb.EJBContext has setRollbackOnly() method, which does exactly what you explained but remember that this method should be called only for container managed transactions.
2. javax.jts.UserTrasaction has rollback() method is used only for bean managed transactions.
If you try to use the incorrect method then that will result in a IllegalStateException.
HTH.

[Vipin Mohan]

hi Ashish
The UserTransaction interface also has a setRollbackOnly() method. I'm confused about when we need to use it instead of the rollback() method.
Thanks
Vipin

[Ashish Pagare]

Here you will get all your answers :
Kathy's comments

[Vipin Mohan]

gee thanks Ashish. Now its crystal clear

Vipin

[Reghu Ram Thanumalayan]

Hello guys,
This is what i have understood.
The setRollbackOnly() method is used to doom a transaction which was started by someone else because we can call rollback() method to doom a transaction we started.
The setRollbackOnly() method called on the EJBContext object, will mark the transaction which was propagated into the CMT ( a transaction started by some other transaction participant ) for rollback.
But the setRollbackOnly() method in javax.transaction.UserTransaction interface can be called within BMT code to set the transaction to be marked for rollback.
But my doubt is that since transactions are not allowed to propagate into BMT code, the transaction must have been started only in the BMT Code. So why cant we just call rollback() instead of setRollbackOnly() ?
In Mastering EJB by Ed Roman ( page no : 305 ) , Its given that �if the transaction participant is not an EJB Component such as a Java Object, we can doom the transaction by looking up the JTA and calling the JTA�s setRollbackOnly() method�.
I am not able to understand what is transaction participant that is a non EJB Component like a Java Object and how can it be included in a transaction?
Even after reading Kathy's explanation, i am not able to get a good reason why rollback() cannot be used in BMT insted of setRollbackOnly(). Can any one help me on this ?

[Vishwa Kumba]

Originally posted by Reghu Ram T:

But my doubt is that since transactions are not allowed to propagate into BMT code, the transaction must have been started only in the BMT Code. So why cant we just call rollback() instead of setRollbackOnly() ?

rollback() method?...Connection Object's rollback() method?.....
There could be other resource manager's datasources obtained in a transaction, apart from the JDBC datasource. It is best if we use UserTransaction's setRollbackOnly() method for BMT and EJBContext's setRollbackOnly() method for CMT for a complete rollback of all the datasources involved in a transaction.

[Vipin Mohan]

hi Reghu
I think its more of a convention to use rollback() only where the transaction actually ends.
Even Kathy has mentioned that she can't think of many good reasons for this.
The following excerpt is from Kathy's post at https://coderanch.com/t/157891/java-EJB-SCBCD/certification/When-UserTransaction-setRollbackOnly-UserTransaction-rollback
"And why would you use it? Because you might know the transaction is going badly *before* you reach the place where the transaction actually ends. You might not want to end the tx at the moment you discover it won't work, for many reasons. Perhaps you want to keep only one place in your code where the transaction ends. Or... you might need the rest of the transactional code to run for other side-effects, who knows.
(I have a hard time coming up with good reasons) "
Hope its clear to you now.
Cheers
Vipin
[ December 22, 2003: Message edited by: Vipin Mohan ]

[Reghu Ram Thanumalayan]

Hi Vish,
I was talking about the rollback() method in the UserTransaction interface.

Even Kathy has mentioned that she can't think of many good reasons for this.
The following excerpt is from Kathy's post at https://coderanch.com/t/157891/java-EJB-SCBCD/certification/When-UserTransaction-setRollbackOnly-UserTransaction-rollback
"And why would you use it? Because you might know the transaction is going badly *before* you reach the place where the transaction actually ends. You might not want to end the tx at the moment you discover it won't work, for many reasons. Perhaps you want to keep only one place in your code where the transaction ends. Or... you might need the rest of the transactional code to run for other side-effects, who knows.
(I have a hard time coming up with good reasons) "

Anyway i had read Kathy's comments and only wanted to know if anyone could come up with more reason's for that ?

[Vishwa Kumba]

Originally posted by Reghu Ram T:
Hi Vish,
I was talking about the rollback() method in the UserTransaction interface.
Anyway i had read Kathy's comments and only wanted to know if anyone could come up with more reason's for that ?

Oops!...Sorry, I didn't look at the right method, Reghu. Even I cannot think of any other reasons..