Rollback

[Oliver Rensen]

Hi,

when a stateless session bean method throws a system-exception, the transaction will be rolled back. But when I catch the system-exception and rethrow an application-exception to the client, will the transaction still be rolled back?

try {
    do some code that throws a system-exception
} catch (SystemException) {
    throw new ApplicationExeption
}

Does this code lead to a rollback?

Kind regards
Oliver

[Ravi kanth P M]

The rollback depends on how you define your application exception. If you are using EJB 3.0, you have provision to set rollback=true or false using annotation @Application Exception.

If the rollback is set to true for your application, then the Transaction will rollback.

[Duran Harris]

and in EJB2.x ?

[Devaka Cooray]

Duran Harris wrote:and in EJB2.x ?

In EJB 2.x, an application exception does not cause the container to roll back a transaction automatically.

[Oliver Rensen]

The following is an excerpt from the book "Pro EJB 3". I like this book very much, but the following example is one of the few things that I have problems to understand:

protected void flushChanges() {
    try {
        em.flush();
    } catch (OptimisticLockException optLockEx) {
        throw new ChangeCollisionException();
    }
}

@ApplicationException
public class ChangeCollisionException extends RuntimeException {
    public ChangeCollisionException() { super(); }
}

The book says:
"The ChangeCollisionException class is annotated with @ApplicationException, which is an EJB 3.0 containter annotation in the javax.ejb package to indicate to the container that the exception is not really a system-level exception but should be thrown back to the client as is. Normally, defining an application exception will cause the container to not roll back the transaction, but this is an EJB 3.0 container notion. The persistence provider that threw OptimisticLockException does not know about the special semantics of designated application exceptions and seeing a runtime exception will go ahead and mark the transaction for rollback."

And the spec says:
" An application exception does not automatically result in marking the transaction for rollback unless the
ApplicationException annotation is applied to the exception class and is specified with the
rollback element value true or the application-exception deployment descriptor element
for the exception specifies the rollback element as true."

In the above example the ApplicationException annotation has no rollback element set to true. I do not understand why "throw new ChangeCollisionException()" causes the transaction to roll back.

[Duran Harris]

Somebody can comment on this??

[Jaikiran Pai]

Oliver Rensen wrote:

In the above example the ApplicationException annotation has no rollback element set to true. I do not understand why "throw new ChangeCollisionException()" causes the transaction to roll back.

It doesn't rollback the transaction. The text you posted doesn't say the transaction is rolled back.

[Duran Harris]

But it says that the persistence provider will mark the transaction for rollback:

Normally, defining an application exception will cause the container to not roll back the transaction, but this is an EJB 3.0 container notion. The persistence provider that threw OptimisticLockException does not know about the special semantics of designated application exceptions and seeing a runtime exception will go ahead and mark the transaction for rollback

[Jaikiran Pai]

Duran Harris wrote:But it says that the persistence provider will mark the transaction for rollback:

Normally, defining an application exception will cause the container to not roll back the transaction, but this is an EJB 3.0 container notion. The persistence provider that threw OptimisticLockException does not know about the special semantics of designated application exceptions and seeing a runtime exception will go ahead and mark the transaction for rollback

Because OptimisticLockException is not marked as a @ApplicationException. It's the ChangeCollisionException which is marked as an @ApplicationException. That's the reason why the OptimisticLockException is being explicitly caught by the bean and converted to a ChangeCollisionException, to avoid the rollback from happening.

[Duran Harris]

Ah I see....Thanks for clearing that up.Wasn't paying attention there.

[Oliver Rensen]

Jaikiran, thank you for the help.

[Duran Harris]

So I would be right if I summarized it as :

EJb 3.0 application exception:doesnt rollback(can force rollback with attribute)
EJb 3.0 system exceptions:causes rollback

EJB 2.x application exception:doesnt rollback(can't be forced)
EJB 2.x system exception causes rollback