Управляемый сообщениями компонент (EJB3) в транзакциях WebSphere 7, XA, Обработка ошибок - PullRequest
8 голосов
/ 28 ноября 2011

Я относительный новичок в EJB.Справочная информация: у меня есть MDB, использующий по умолчанию поставщик сообщений WebSphere, получающий MapMessages, у которого есть java.sql.DataSource для выполнения некоторой работы, с использованием подготовленного состояния, транзакции jdbc и т. Д. Я устанавливаю MDB в ibm-ejb-bnd.xml иejb-jar.xml с использованием адаптера JCA со спецификацией активации и именем назначения.Я добавил java.sql.DataSource в ejb-jar и ibm-ejb-jar-bind.Я также добавил DataSource в MessageListener с аннотацией @Resource.

2 сценария У меня проблемы с пониманием (первый сценарий исправлен, см. Обновление) ...

Управляемый контейнером MDB: Драйвер DataSource не совместим с XA, поэтому я включил«Поддержка последнего участника» в WebSphere.Тем не менее, когда тип транзакции MDB установлен в значение «Контейнер», я получаю сообщение об ошибке при фиксации:

[11/28/11 10:56:10:988 MST] 0000002e RegisteredRes E   WTRN0063E: An illegal attempt to commit a one phase capable resource with existing two phase capable resources has occurred.

Может быть, это потому, что после фиксации DataSource возвращается к MessageListener, который делает его последним участником?Я считаю, что провайдер обмена сообщениями по умолчанию в WAS 7 совместим с XA, хотя я не видел ни одной документации, в которой говорится об этом явно.

Сообщение перезапускается еще 4 раза сразу после первой ошибки (даже если должно быть 30вторая задержка в соответствии со ActivationSpec в WebSphere).Каждый раз выдается одна и та же ошибка.Согласно MessageListener, он завершился без ошибок, поэтому эта ошибка является частью замечательной транзакции, управляемой невидимым контейнером.Я не думаю, что мне нужны глобальные транзакции XA, поскольку кроме JMS есть только один источник данных, я обработал откат транзакции программно.Также JMS msg, MDB является асинхронным, AUTO-ACKNOWLEDGE.Как только сообщение получено, оно может быть подтверждено.

Если я ввожу ошибку приложения, поэтому возникает исключение, я сразу вижу эту ошибку 5 раз (без задержки):

[11/28/11 10:16:18:857 MST] 0000002b LocalExceptio E   CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "onMessage" on bean...

Поэтому я переключился на ................

MDB, управляемый компонентом Bean: Commit работает без ошибки XA и происходит только один раз.Однако обработка ошибок все еще не ведет себя так, как я ожидаю или хочу!В классе MessageListener перехваченные исключения генерируют исключение EJB, которое, я думаю, должно заставить MDB иметь желаемое поведение: Причина исключения не имеет значения для меня, когда MDB выдает перехваченное исключение, не должноMDB нужно повторить в соответствии со свойствами в WebSphereActivationSpec? Вместо этого сообщение отправляется в MessageListener 5 раз, сразу же выдавая ту же ошибку, что и MDB, управляемый контейнером: «EJB выдал неожиданное (не объявленное) исключение ...»

Если я сгенерирую исключение RuntimeException, сообщение «невыполненное (не объявленное) исключение» не появится, но оно все равно будет немедленно повторено 4 раза, вместо ожидания задержки повтора.

Спасибо за чтение, любая помощь или понимание очень важны!

ОБНОВЛЕНИЕ: Я решил проблему совместимости с XA, переключив источник данных на XA-совместимый.В консоли администратора WAS: Ресурсы-> Поставщики JDBC-> Поставщик универсального драйвера JDBC DB2-> Изменить имя класса реализации на: com.ibm.db2.jcc.DB2XADataSource

У меня все еще остается та же проблема, когдасообщение не удается, хотяПовторяется немедленно, вместо того, чтобы соответствовать спецификации активации в WAS.

Ответы [ 2 ]

4 голосов
/ 10 января 2012

Я полагаю, что интервал повторения в спецификации активации относится к закрытым соединениям, а не к ошибочным сообщениям.

Вы должны определить нужный интервал в пункте назначения SIB

Автобусы> АВТОБУС> Направления> DESTINATION

Посмотрите на Исключение

Максимальное количество неудачных доставок на сообщение - сколько раз сообщение будет отправлено до тех пор, пока оно не будет объявлено неудачным (по умолчанию 5, поэтому вы получаете еще 4 раза)

При сбое сообщений оно либо перемещается в очередь назначения исключений, либо, если установлено значение «Нет», будет повторять попытки через определенное время, заданное на уровне шины, но может быть переопределено для каждого пункта назначения (см. Блокировка механизма переопределения сообщений. тайм-аут по умолчанию)

0 голосов
/ 23 марта 2012

Не знаю, нужно ли вам это по-прежнему, но вы должны проверить пользовательское свойство: sib.processor.blockedRetryTimeout, определенное для механизма обмена сообщениями.

Это то, что вы ищете, во время сообщенияожидает доставки, находится в состоянии UNLOCKED и может быть впоследствии удалено.

...