Изучаем Java EE 7 - [210]
>@PersistenceContext
>private EntityManager em;
>@Inject
>private InvoiceBean invoice;
>@Resource(lookup = "jms/javaee7/ConnectionFactory")
>private ConnectionFactory connectionFactory;
Контекст MDB также может быть внедрен с помощью аннотации @Resource:
>@Resource private MessageDrivenContext context;
Контекст MDB
Интерфейс MessageDrivenContext обеспечивает доступ к среде выполнения контекста, которую контейнер предоставляет объекту MDB. Контейнер передает этому объекту интерфейс MessageDrivenContext, с которым объект остается связанным на протяжении всего срока службы MDB. Это дает возможность MDB явно откатывать транзакции, получать принципал пользователя и т. д. Интерфейс MessageDrivenContext расширяет интерфейс javax.ejb.EJBContext без добавления каких-либо дополнительных методов.
Если MDB внедряют ссылку на их контекст, они будут иметь возможность ссылаться на методы, перечисленные в табл. 13.9.
| Метод | Описание |
|---|---|
| getCallerPrincipal | Возвращает java.security.Principal, связанный с вызовом |
| getRollbackOnly | Проверяет, помечена ли для отката текущая транзакция |
| getTimerService | Возвращает интерфейс javax.ejb.TimerService |
| getUserTransaction | Возвращает интерфейс javax.transaction.UserTransaction, который будет использован для разграничения транзакций. Только MDB, транзакции которых управляются компонентами (BMT), могут применять этот метод |
| isCallerInRole | Проверяет, имеет ли вызывающая сторона заданную роль безопасности |
| Lookup | Позволяет MDB выполнить поиск по записям среды контекста именования JNDI |
| setRollbackOnly | Позволяет объекту пометить текущую транзакцию для отката. Только MDB с BMT могут использовать этот метод |
Жизненный цикл и аннотации функций обратного вызова
Цикл жизни MDB (рис. 13.12) идентичен жизненному циклу сессионного компонента: либо MDB существует и готов потреблять сообщения, либо не существует. Перед выходом контейнер сначала создает экземпляр MDB и, если это возможно, внедряет необходимые ресурсы, как указано в аннотациях метаданных (@Resource, @Inject, @EJB и т. д.) или дескрипторах развертывания. Затем контейнер вызывает метод обратного вызова компонента @PostConstruct, если таковой имеется. После этого MDB находится в состоянии готовности и ожидает, чтобы потребить входящие сообщения. Метод обратного вызова @PreDestroy вызывается, когда MDB удаляется из хранилища или уничтожается.
Рис. 13.12. Жизненный цикл MDB
Такое поведение идентично поведению сессионных компонентов, не сохраняющих состояние (для получения более подробной информации о методах обратного вызова см. главу 8), и, как и для других компонентов EJB, вы можете добавить перехватчики с помощью аннотации @javax.ejb.AroundInvoke.
MDB как потребитель
Как было показано в разделе «Написание потребителей сообщений» ранее в этой главе, потребители могут получить сообщение синхронно, запустив цикл и ожидая поступления сообщения, или асинхронно путем реализации интерфейса MessageListener. По своей природе MDB рассчитан на то, чтобы быть асинхронным потребителем сообщений. MDB реализует интерфейс слушателя сообщений, который по приходе сообщения вызывается контейнером.
Может ли MDB быть синхронным потребителем? Да, но это не рекомендуется. Синхронные потребители сообщений блокируют и связывают ресурсы сервера (EJB застрянут в цикле, не выполняя никакой работы, и контейнер не сможет освободить их). MDB, как и сессионные компоненты, не сохраняющие состояния, живут в хранилище определенного размера. Когда контейнеру нужен объект, он выбирает один из хранилища и использует его. Если каждый экземпляр уйдет в бесконечный цикл, хранилище в итоге опустеет и все доступные экземпляры будут заняты в цикле. Контейнер EJB также может начать производить больше объектов MDB, что увеличит хранилище и съест больше памяти. По этой причине сессионные компоненты и MDB не должны использоваться в качестве синхронных потребителей сообщений. В табл. 13.10 показаны разные режимы для MDB и сессионных компонентов.
| Компонент | Производитель | Синхронный потребитель | Асинхронный потребитель |
|---|---|---|---|
| Сессионный компонент | Да | Не рекомендуется | Невозможно |
| MDB | Да | Не рекомендуется | Да |
MDB как производитель сообщений
MDB способны стать производителями сообщений, что часто происходит, когда они участвуют в рабочем процессе, так как они получают сообщение от одного адресата, обрабатывают его и отправляют в другое место назначения. Чтобы использовать эту возможность, следует применить JMS API.
Место назначения и фабрику соединений можно внедрить с помощью аннотаций @Resource и @JMSConnectionFactory или через поиск JNDI. Затем могут быть вызваны методы объекта javax.jms.JMSContext для создания и отправки сообщения. Код BillingMDB (листинг 13.13) слушает тему (jms/javaee7/Topic), получает сообщения (метод onMessage()) и посылает новое сообщение в очередь (jms/javaee7/Queue).
>@MessageDriven(mappedName = "jms/javaee7/Topic", activationConfig = {
>········@ActivationConfigProperty(propertyName··= "acknowledgeMode",
