I'm using CMT in EJB3 state-less session beans. Also I've created my own Exception having the annotation "@ApplicationException (rollback=true)".
Do I have to use "context.setRollbackOnly()" when I want to rollback the transaction?
Can I just rollback the transaction by throwing an exception inside public method in the bean?
If so (the answer to Q#2 is yes) do I have to throw the exception out of the method by declaring the exception in the method or will it be sufficient to just throw an exception inside the method and handle it inside the same method itself? (I don't want to propagate the exception to the next level. I just want to rollback the exception.)
Thanks in advance. ;)
First of all, there is no rollback of an exception, it's a rollback of a transaction.
- If you throw your exception with
@ApplicationException(rollback=true), you don't have to rollback the transaction manually. Context.setRollbackOnly() forces the container to rollback the transaction, also if there is no exception.
- A checked exception itself doesn't rollback a transaction. It needs to have the annotation
@ApplicationException(rollback=true). If the exception is a RuntimeException and the exception isn't caught, it forces the container to rollback the transaction. But watch out, the container will in this case discard the EJB instance.
- As mentioned in 2.), if you throw a
RuntimeException, the transaction will be rolled back automatically. If you catch an checked exception inside the code, you have to use setRollbackOnly to rollback the transaction.
For further information, check out the free book Mastering EJB. It describes the rollback scenarios very well and is free for download.
The question of how to prevent checked exceptions annotationally declared to cause a rollback on throwing from being propagated to the "upper layer" is not yet answered here.
I think that this will require a wrapper around the EJB in question which swallows the thrown exception. (In other words: I think that the custom exception MUST be thrown against method boundary (and thus not catched & processed inside the method) AND propagated to take transactional effect -- and also will in turn cause destruction of the EJB instance.)
