Spring’s @Transactional does not rollback on checked exceptions

We’re using the Spring Framework in most of our applications (and thus also in the Catalysts Platform) and are really satisfied with it.

One of the big advantages is the the declarative transaction handling using the @Transactional attribute.

import org.springframework.transaction.Transactional;
 
@Transactional
public class MyService implements IMyService {
  public List getResults () {
    // do something
  }
 
  public void foo() {
    throw new java.lang.UnsupportedOperationException();
  }
 
  public void bar() {
    throw new java.lang.Exception();
  }
}

That simple annoation on class managed by a Spring ApplicationContext causes all method calls onto that service to be bound to a transaction. The transaction is committed after the method call has left the service again and it’s rollbacked for the case an exception is thrown (e.g. after calling the (quite silly) method foo()).

But be careful: Only unchecked exceptions (that is, subclasses of java.lang.RuntimeException) are rollbacked by default. For the case, a checked exception is thrown, the transaction will be committed!

The Spring documentation explains that as follows:

While the EJB default behavior is for the EJB container to automatically roll back the transaction on a system exception (usually a runtime exception), EJB CMT does not roll back the transaction automatically on an application exception (that is, a checked exception other than java.rmi.RemoteException). While the Spring default behavior for declarative transaction management follows EJB convention (roll back is automatic only on unchecked exceptions), it is often useful to customize this.

And that customization can be done very easily by just adding the parameter rollBackFor to the @Transactional attribute:

import org.springframework.transaction.Transactional;
 
@Transactional(rollbackFor = Exception.class)
public class MyService implements IMyService {
  public List getResults () {
    // do something
  }
 
  public void foo() {
    throw new java.lang.UnsupportedOperationException();
  }
 
  public void bar() {
    throw new java.lang.Exception();
  }
}

In that case, the transaction will even be be rollbacked on a call to the method bar().

Are you the expert we should hire?

Menu