Изучаем Java EE 7 - [122]

Таблица 7.3. Методы интерфейса SessionContext

Метод	Описание
etCallerPrincipal	Возвращает java.security.Principal, ассоциированный с вызовом
getRollbackOnly	Проверяет, была ли текущая транзакция помечена как подлежащая откату
getTimerService	Возвращает интерфейс javax.ejb.TimerService. Только EJB-компоненты без сохранения состояния и одиночные EJB-компоненты могут задействовать этот метод. Сессионные EJB-компоненты с сохранением состояния не могут быть синхронизированными объектами
getUserTransaction	Возвращает интерфейс javax.transaction.UserTransaction для ограничения транзакций. Только сессионные EJB-компоненты, для которых имеет место транзакция, управляемая EJB-компонентом (Bean-Managed Transaction — BMT), могут задействовать этот метод
isCallerInRole	Проверяет, имеется ли у вызывающего оператора определенная роль безопасности
lookup	Дает возможность сессионному EJB-компоненту осуществлять поиск его записей окружения в контексте именования JNDI
setRollbackOnly	Позволяет EJB-компоненту пометить текущую транзакцию как подлежащую откату
wasCancelCalled	Проверяет, вызвал ли клиент метод cancel() в клиентском объекте Future, который соответствует выполняющемуся в текущий момент асинхронному бизнес-методу

Как показано в листинге 7.15, сессионный EJB-компонент может получить доступ к своему контексту среды путем внедрения ссылки на SessionContext с использованием аннотации @Resource. Здесь метод createBook удостоверяется в том, что только администраторы могут создавать экземпляры Book. Он также осуществляет откат, если уровень запасов книг оказывается слишком высоким.

Листинг 7.15. EJB-компонент без сохранения состояния, осуществляющий доступ к API-интерфейсу SessionContext

@Stateless
public class ItemEJB {
··@PersistenceContext(unitName = "chapter07PU")
··private EntityManager em;
··@Resource
··private SessionContext context;
··public Book createBook(Book book) {
····if (!context.isCallerInRole("admin"))
······throw new SecurityException("Только администратор может создавать
···································книги");
····em.persist(book);
····if (inventoryLevel(book) == TOO_MANY_BOOKS)
······context.setRollbackOnly();
····return book;
··}
}

Асинхронные вызовы

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

До выхода EJB 3.1 асинхронная обработка могла осуществляться только благодаря JMS и EJB-компонентам, управляемым сообщениями (см. главу 13). Вам приходилось создавать администрируемые объекты (фабрики и пункты назначения JMS), иметь дело с низкоуровневым JMS API для отправки сообщения в пункт назначения, а затем разрабатывать EJB-компонент, управляемый сообщениями, который принял и обработал бы ваше сообщение. JMS сопутствуют хорошие механизмы обеспечения надежности (постоянное хранилище сообщений, гарантии доставки, интеграция с другими системами и т. д.), однако все это может оказаться тяжеловесным при таких сценариях, когда вам требуется просто вызвать метод асинхронно.

С выходом EJB 3.1 у вас появилась возможность вызывать методы асинхронно, просто снабдив метод сессионного EJB-компонента аннотацией @javax.ejb.Asynchronous. В листинге 7.16 приведен OrderEJB, у которого имеется один метод для отправки клиенту сообщений по электронной почте и другой метод для печати заказа. Поскольку выполнение обоих методов занимает много времени, они оба снабжены аннотацией @Asynchronous.

Листинг 7.16. OrderEJB, для которого объявляются асинхронные методы

@Stateless
public class OrderEJB {
··@Asynchronous
··public void sendEmailOrderComplete(Order order, Customer customer) {
····// Задача, на решение которой требуется очень много времени
··}

··@Asynchronous
··public void printOrder(Order order) {
····// Задача, на решение которой требуется очень много времени
··}
}

Когда клиент вызывает метод printOrder() либо sendEmailOrderComplete(), контейнер незамедлительно возвращает управление клиенту и продолжает обработку вызова в отдельном потоке выполнения. Как вы можете видеть в листинге 7.16, возвращаемым типом двух асинхронных методов является void. Возможно, это окажется подходящим при подавляющем большинстве сценариев использования, однако иногда возникает необходимость возвратить значение. Асинхронный метод может возвратить void, а также объект java.util.concurrent.Future, где V представляет результирующее значение. Объекты Future позволяют вам получить возвращаемое значение с помощью метода, выполняемого в отдельном потоке. Кроме того, клиент может прибегнуть к API-интерфейсу Future, чтобы получить результат или даже отметить вызов.