For the previous past posts, I have dealth much with manual fine-grind transaction, mostly on the subject of Bean-Managed Transaction with javax.ejb.UserTransaction and I’ve talked about what were the differences between rollback() and setRollbackOnly(). Don’t be surprise that Container-Managed Transaction could achieve similar control over transaction if transaction demarcates are properly used. I am writting a series of linked-articles to address usage of @TransactionAttribute with TransactionAttributeType such as REQUIRES_NEW, MANDATORY, SUPPORTS, NOT_SUPPORTED and NEVER.
After JTA was introduced for more than a decade ago, then later with the introduction of Bean-Managed Transaction and Container-Managed Transaction in the J2EE 1.2 specs; still, there are many developers, especially those whom had just gotten their feets wet in the marvelous world of Java EE programming were confused when to and not to use the rollback() and the setRollbackOnly() method in the UserTransaction or the EJBContext class. Perhaps you may be coding fine grind transactional methods and have no idea why expections are all over the place and the rollback() or setRollbackOnly() just doesn’t seem to perform according to your expectation. You might think that both methods are the same (but its not). Is this the reason why you have landed on this page through google or through other web sources trying to shade some light?
There are times when handling of data transaction requires a little craftiness where transaction begins, commits and rollbacks could not be a straight-forward one. This is the time when Bean-Managed Transaction comes to play for business process that requires some lengthy customized units of transaction.