sebastiandaschner blog


Transactional exception handling in CDI

monday, january 01, 2018

In Java EE, exceptions that are raised during the execution of a transactional business method cause the transaction to rollback. However, this is only the case for system exceptions, that is, runtime exceptions, which are not declared in the method signature.

For application exceptions, that is, checked exceptions, or any exception annotated with @ApplicationException, the transaction is not automatically rolled back. This sometimes causes confusion among enterprise developers.

For EJB business methods, the transactions can be forced to roll back on application exceptions as well, by specifying @ApplicationException(rollback = true). However, this annotation is only considered if the managed bean in an EJB.

CDI also makes it possible to execute business methods transactionally, using @Transactional. This annotation gives us even more control. With @Transactional we can not only define the transaction type, such as REQUIRED or REQUIRES_NEW, but also on which exception types we do or do not want to rollback:

public class CarManufacturer {

    @Inject
    CarFactory carFactory;

    @Inject
    Event<CarCreated> createdCars;

    @PersistenceContext
    EntityManager entityManager;

    @Transactional(rollbackOn = CarCreationException.class,
            dontRollbackOn = NotificationException.class)
    public Car manufactureCar(Specification specification) {
        Car car = carFactory.createCar(specification);
        entityManager.persist(car);
        createdCars.fire(new CarCreated(car.getIdentification()));
        return car;
    }

}

The transaction will be rolled back in case a CarCreationException occurs, but not for NotificationExceptions.

This post was reposted from my newsletter issue 016

 

Found the post useful? Subscribe to my newsletter for more free content, tips and tricks on IT & Java: