rollback() after setRollBackOnly()?

The bean law is that a BMT bean using a UserTransaction should end its transaction by commit() or rollback() before the end of the method (except for stateful session beans) but if it find early in its application logic that it cannot end with commit may it do a call to setRollbackOnly() on its UserTransaction. A CMT bean can also call setRollbackOnly() on the EJBContext which is a way for it to tell the container that it must NOT commit the transaction. But unlike the CMT bean does a BMT bean have access to a rollback() method and it is the bean that manage the transaction. Does the BMT bean then still have to call its rollback() method after itself or some of the methods it have called have made a call to setRollbackOnly()? That is, is setRollbackOnly() in UserTransaction only a way to set a flag (which they calle status) that the container not care of? I guess so but I am not sure and have not found any clear note about it. Does anyone know?

May they have questions that is THIS tricky on the exam? As there not already is enough details to memorize as it is.

[ June 20, 2007: Message edited by: Jonny Andersson ]
[ June 20, 2007: Message edited by: Jonny Andersson ]

We can call getStatus of UserTransaction to know the status and see if we should do commit or rollback.

What happens when we call commit after doing setRollbackOnly on UserTransaction?

We can call getStatus of UserTransaction to know the status and see if we should do commit or rollback.

... and to avoid execution of a lot of code if the transaction is already deemed to death.

What happens when we call commit after doing setRollbackOnly on UserTransaction?

Even if it would be a bit stupid (but it is often instructive to test stupid things

) should it work if the setRollbackOnly in UserTransaction just only modifies the flag for getStatus() and the container not care of that flag.

But IF the container care of that flag would an error occur and in that case, would it not be enough to just skip the call of rollback()? But with bean managed transactions is it the bean that has to manage the transaction and my guess is therefore that the container not care and that it would be an error to not call rollback() because that would leave the method with an open transaction. And I therefore also think it would work with a call to commit() instead of rollback() despite it would be somewhat stupid.

But someone that really know about this are welcome to confirm what is true according to bean law!
[ June 21, 2007: Message edited by: Jonny Andersson ]