Изучаем Java EE 7 полностью

Еще один способ программно информировать контейнер об откате — сгенерировать исключение определенного типа.

Обработка исключений в Java вводит в заблуждение с момента создания языка, поскольку она включает в себя как проверенные, так и непроверенные исключения. Связывание транзакций и исключений в EJB также весьма сложное дело. Прежде чем идти дальше, я хочу сказать, что генерация исключения в бизнес-метод не всегда пометит транзакцию как готовую для отката. Это зависит от типа исключения и метаданных, определяющих исключение. На самом деле в спецификации EJB 3.2 описаны два типа исключений.

• Исключения приложения — исключения связаны с бизнес-логикой, обрабатываемой EJB. Например, исключения приложения могут быть сгенерированы, если методу переданы неверные аргументы, количество предметов на складе невелико или же указан ошибочный номер кредитной карты. Генерация исключения приложения не гарантирует, что транзакция будет помечена для отката. Как будет подробно описано в табл. 9.4, контейнер не откатывает транзакции при генерации проверенных исключений (которые наследуют от класса java.lang.Exception), в случае непроверенных исключений (которые наследуют от класса RuntimeException) пометка добавляется.

• Системные исключения — исключения, вызванные неполадками системного уровня, такие как JNDI-ошибки, JVM-ошибки, неспособность получить соединение с базой данных и т. д. Системное исключение должно быть исключением подкласса RuntimeException или java.rmi.RemoteException (и, следовательно, подкласса javax.ejb.EJBException). Генерация системного исключения приводит к тому, что транзакция помечается для отката.

Исходя из этого определения, мы теперь знаем, что, если контейнер обнаружит системное исключение, такое как ArithmeticException, ClassCastException, IllegalArgumentException или NullPointerException, он откатит транзакцию. Действия при генерации исключения приложения зависят от многих факторов. В качестве примера изменим код листинга 9.3 и используем исключения приложения, как показано в листинге 9.4.

@Stateless

public class InventoryEJB {

··@PersistenceContext(unitName = "chapter09PU")

··private EntityManager em;

··public void oneItemSold(Item item) throws InventoryLevelTooLowException{

····item.decreaseAvailableStock();

····sendShippingMessage();

····if (inventoryLevel(item) == 0)

······throw new InventoryLevelTooLowException();

··}

}

InventoryLevelTooLowException — это исключение приложения, потому что оно связано с бизнес-логикой метода oneItemSold(). Знать, хотите ли вы откатить транзакцию, — обязанность бизнес-логики. Исключение приложения наследует от проверенных и непроверенных исключений и имеет аннотацию @javax.ejb.ApplicationException (или эквивалент в XML в дескрипторе развертывания). Эта аннотация включает элемент rollback, которому может быть присвоено значение true для того, чтобы откатить транзакцию. В листинге 9.5 показано исключение InventoryLevelTooLowException, которое является аннотированным проверенным исключением.

@ApplicationException(rollback = true)

public class InventoryLevelTooLowException extends Exception {

··public InventoryLevelTooLowException() { }

··public InventoryLevelTooLowException(String message) {

····super(message);

··}

}

Если InventoryEJB из листинга 9.4 сгенерирует исключение, определенное в листинге 9.5, транзакция будет помечена для отката и контейнер сделает фактический откат, когда наступит время завершения транзакции. Это произойдет потому, что InventoryLevelTooLowException имеет аннотацию @ApplicationException(rollback = true). В табл. 9.4 показаны все возможные комбинации с применением исключения. Первая строка таблицы может быть истолкована как «Если исключение приложения наследует от класса Exception и не имеет аннотации @ApplicationException, то генерация такого исключения будет означать, что транзакция не будет отмечена для отката.