EJB 3.x onMessage () против транзакционного контекста @Timeout - PullRequest
2 голосов
/ 04 мая 2011

в EJB 3.x как для метода onMessage() для MDB, так и для метода @Timeout для SLSB и MDB нет распространения транзакции. То есть клиент для выполнения метода отсутствует, поэтому транзакция не может быть распространена.

При использовании транзакций, управляемых контейнером, я ожидаю, что два случая примут одинаковые javax.ejb.TransactionAttributeType. Однако они этого не делают.

Для метода onMessage(), REQUIRED и NOT_SUPPORTED являются приемлемыми атрибутами транзакции, тогда как для @Timeout методов REQUIRED, REQUIRES_NEW и NOT_SUPPORTED.

В частности, для методов @Timeout в спецификации говорится (пар. 18.2.8):

Обратите внимание, что контейнер должен начинать новая транзакция, если ТРЕБУЕТСЯ (Обязательный) атрибут транзакции используемый. Это значение атрибута транзакции разрешено, так что спецификация атрибут транзакции для тайм-аута Метод обратного вызова может быть установлен по умолчанию.

Если я получаю это правильно, обычно REQUIRES_NEW должен использоваться здесь, но поскольку REQUIRED является значением по умолчанию для EJB, он также разрешен для @Timeout методов, предоставляя ему ту же семантику, что и REQUIRES_NEW, поскольку нет возможности транзакция для распространения.

Вопросы:

  1. Правильно ли мое понимание?
  2. Почему REQUIRES_NEW неприемлемо также в onMessage()? Отличается ли как-то в отношении транзакций?

UPDATE: То же самое касается других случаев, где поддерживается REQUIRES_NEW: методы @Asynchronous и @ PostConstruct / @ PreDestroy.

1 Ответ

2 голосов
/ 04 мая 2011
  1. Да, ваше понимание верно.

  2. На мой взгляд, @Timeout странно для указания REQUIRES_NEW.Спецификация в основном требует, чтобы контейнер обновлял базу данных постоянного таймера в той же транзакции, что и метод тайм-аута.На самом деле это ничем не отличается от транзакционной доставки сообщений JCA, за исключением того, что в сценарии JCA более очевидно, что внешний компонент обрабатывает транзакцию.Я полагаю, вы могли бы утверждать, что нет компонента JavaEE, управляющего методом @Timeout, но, по моему мнению, было бы лучше запретить REQUIRES_NEW для обоих.Несмотря на это, несоответствие является странным, поэтому, возможно, MDB будет обновлен в более поздней версии спецификации, чтобы разрешить REQUIRES_NEW.

...