EJB3 transaction rollback

Question

I'm using CMT in EJB3 state-less session beans. Also I've created my own Exception having the annotation "@ApplicationException (rollback=true)".

1. Do I have to use "context.setRollbackOnly()" when I want to rollback the transaction?

2. Can I just rollback the transaction by throwing an exception inside public method in the bean?

3. 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. ;)

Drift

Answer 1

First of all, there is no rollback of an exception, it's a rollback of a transaction.

1. 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.
2. 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.
3. 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.

Tabard

"If you catch an checked exception inside the code, you have to use setRollbackOnly to rollback the transaction." Can you also throw the same exception and rollback the transaction? – Drift

You can throw the same exception with the throws clause, but the transaction doesn't get rolled back. If you want to rollback the transaction in this case, you have to add the @ApplicationException(rollback=true) to your exception. Another way is to wrap the checked exception inside a unchecked exception (e.g. RuntimeException). But this way is not really preferred, because if a RuntimeException is thrown, the container discards the bean instance and creates a new one. – Tabard

I was just looking at this answer for similar reasons and want to point out that the book you link to is no longer offered in full at that site, and it is from 2006 so it is terribly dated and probably not of much use in JEE5 and JEE6 contexts. – Acyclic

EJB 3.1 final spec says that an Application Exception is any ChechedException or RuntimeException annotated with @ApplicationException – Triclinic

Seems to me like exceptionally bad behaviour, if there is an exception IMO obviously there should be a rollback!! Anybody knows why it is like it is? – Unexpected

@EmmanuelTouzery: Checked Exceptions are part of the method's signature and are therefore regarded as "expected" and non-errorneus behaviour. Now, some people use checked exceptions as regular response of the method, instead of returning a value. For example, it could carry information about the outcome of a business case. That's why checked Exceptions don't rollback transactions by default (are part of the signature), but RuntimeExceptions do (are not part of the signature). – Thorstein

Answer 2

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.)

Osteomalacia