aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes About setRollbackOnly method in a transaction Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "About setRollbackOnly method in a transaction" Watch "About setRollbackOnly method in a transaction" New topic
Author

About setRollbackOnly method in a transaction

Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 801
    
    1
On p.177 of EJB in Action,

The setRollbackOnly mehtod on the EJBContext can only be used in methods that have a transaction attribute type of REQUIRE, REQUIRED_NEW or MANDATORY. If a transactions hasn't been started, as in the case of SUPPORTED or NEVER, a java.lang.IllegalStateException will be thrown.


What about this case ?
A method is annotated with a transaction attribute type of SUPPORT. And this method will join an existing transaction. Can we roll back changes in this method ? I assume we cannot roll back changes in such a method, based on this quote. Then, is it possible to roll back any changes?
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
The specs say
Only enterprise beans that will execute correctly in both modes should use the SUPPORTS transaction attribute.

You can't guarantee that the method will be called with a transaction present so you wouldn't know when to do the rollback and when not to. If a transaction exists it will probably work because the specs only say the exception is thrown if "the instance is not allowed to use this method (i.e. the instance is of a bean with bean-managed transactions)." but it will be very bad practice to use transaction semantics in a method marked as SUPPORTS.
Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 801
    
    1
Thanks for your reply.
So, using the placeOrder() method in the EJB in Action as an example:
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
Whether it will throw an exception or not could be implementation specific. The API specs don't explicitly say what will happen. The code is a contradiction. It declares that the method doesn't care about the presence of a transaction and yet it goes on to try and use it.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: About setRollbackOnly method in a transaction