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.
| Published on Java Code Geeks with permission by Sebastian Daschner, partner at our JCG program. See the original article here: Transactional exception handling in CDI Opinions expressed by Java Code Geeks contributors are their own. |
