setRollBack()

[Mike Yu]

In javax.transaction.UserTransaction, there is setRollbackOnly() method. Can some tell me when we should use this setRollbackOnly()method ?


------------------
Thanks,
Mike

[Kyle Brown]

When you have a question like this, you should first do a search on JavaRanch to see if anyone has asked this question before. In fact, right below on the page (on this thread) someone answered the same question.
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

[Mike Yu]

Originally posted by Kyle Brown:
When you have a question like this, you should first do a search on JavaRanch to see if anyone has asked this question before. In fact, right below on the page (on this thread) someone answered the same question.
Kyle

Hi Kyle,
That question was asked by myself and answered by Marco. I had a further question posted after Marco's anwser. The second question was not anwsered. This is why I posted the above question. Can you go to my previous question and give me an anwser? Many thanks!


------------------
Thanks,
Mike

[Kyle Brown]

Hmmm... This might be reaching a bit. Someone else can probably come up with a better example. Personally, I think that it's probably there for symmetry with the EJB interface, but...
If you are using BMT, then sometimes you may be way deep inside of a transaction and discover that you need to roll the transaction back. Well, the problem is one of scope -- if you invoke a rollback() deep inside your call tree everything will proceed hunky-dory until later back up in the call tree someone tries to do a commit() -- and then they'll get an uninformative IllegalStateException thrown at the commit.
So instead, when you get to a point where you decide a transaction cannot commit (for instance, the spec talks about doing this prior to throwing an exception) you can mark the transaction as rollback only -- even if your code doesn't look to see the transaction state and tries to commit, it will still end up rolling back -- and the commit() will throw the slightly more meaningful "RollbackException".
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

[Mike Yu]

Originally posted by Kyle Brown:
Hmmm... This might be reaching a bit. Someone else can probably come up with a better example. Personally, I think that it's probably there for symmetry with the EJB interface, but...
If you are using BMT, then sometimes you may be way deep inside of a transaction and discover that you need to roll the transaction back. Well, the problem is one of scope -- if you invoke a rollback() deep inside your call tree everything will proceed hunky-dory until later back up in the call tree someone tries to do a commit() -- and then they'll get an uninformative IllegalStateException thrown at the commit.
So instead, when you get to a point where you decide a transaction cannot commit (for instance, the spec talks about doing this prior to throwing an exception) you can mark the transaction as rollback only -- even if your code doesn't look to see the transaction state and tries to commit, it will still end up rolling back -- and the commit() will throw the slightly more meaningful "RollbackException".
Kyle

Thanks Kyle, your explanation gives me a meaningful picture. I still hope to see more examples from others.

------------------
Thanks,
Mike