Управляемый сообщениями компонент (EJB3) в WebSphere 7, транзакции XA, обработка ошибок
Я относительный новичок в EJB. Фон: у меня есть MDB, использующий поставщик сообщений WebSphere по умолчанию, получающий MapMessages с java.язык SQL.DataSource для выполнения некоторой работы, используя preparedstatement, транзакцию jdbc и т. д. Я установил MDB в ibm-ejb-bnd.в XML-и EJB-банку.xml с использованием адаптера JCA со спецификацией активации и именем назначения. Я добавил java.язык SQL.Источник данных в ejb-jar и ibm-ejb-jar-bind. Я также добавил источник данных в MessageListener с @ Resource аннотация.
2 сценария у меня возникли проблемы с пониманием (первый сценарий исправлен, см. обновление)...
контейнер управляемый MDB: Драйвер источника данных не совместим с 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.
возможно, это потому, что после фиксации источника данных возвращается MessageListener, который фиксирует его последним участник? Я считаю, что поставщик сообщений по умолчанию в WAS 7 совместим с XA, хотя я не видел никакой документации, которая говорит об этом явно.
сообщение повторяется еще 4 раза сразу после первой ошибки (хотя в WebSphere должна быть 30-секундная задержка в соответствии с ActivationSpec). Каждый раз возникает одна и та же ошибка. Согласно MessageListener он закончил без ошибки, поэтому эта ошибка является частью замечательного невидимого управляемого контейнера торговая операция. Я не думаю, что мне нужны глобальные транзакции XA, так как есть только один источник данных помимо JMS, я обработал откат транзакции программно. Также JMS msg, MDB является асинхронным, автоматически подтверждает. Как только сообщение получено, его можно подтвердить.
Если я введу ошибку приложения, поэтому есть исключение, я вижу эту ошибку 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: Commit работает без ошибки XA и происходит только один раз. Однако обработка ошибок по-прежнему не ведет себя так, как я ожидаю или хочу! В классе MessageListener пойманные исключения вызывают исключение EJB, которое, я думаю, должно привести к тому, что MDB будет иметь мое желаемое поведение:причина исключения для меня не имеет значения, когда MDB выдает пойманное исключение, не должен ли MDB быть повторен в соответствии со свойствами в WebSphereActivationSpec? вместо сообщение переходит к MessageListener 5 раз сразу, бросая ту же ошибку, что и управляемый контейнером MDB: "EJB бросил неожиданное (не объявленное) исключение..."
Если я создаю исключение RuntimeException, сообщение" unexpeded (non-declared) expecetion " не происходит, но сообщение по-прежнему повторяется 4 раза сразу, вместо ожидания задержки повторной попытки.
Спасибо за чтение, любая помощь или понимание будет высоко оценен!
обновление: Я закончил решение проблем совместимости XA путем переключения источника данных на совместимость с XA. В консоли администратора WAS: ресурсы - >поставщики JDBC - >поставщик драйверов DB2 Universal JDBC - >измените имя класса реализации на: com.компания IBM.в DB2.СКК.DB2XADataSource
у меня все еще есть та же проблема, когда сообщение терпит неудачу. Он повторяется немедленно, а не в соответствии с ActivationSpec в WAS.
2 ответов
Я считаю, что интервал повтора в спецификации активации касается закрытых соединений, а не сообщений об ошибках.
вы должны определить интервал, который вы хотите в Sib назначения
автобусов > автобус > направления > пунктом
посмотрите на пункт назначения исключения
максимальные неудачные доставки на сообщение - это сколько раз сообщение будет отправлено, пока оно не будет объявлено неудачным (по умолчанию 5, поэтому вы получаете еще 4 раза)
когда сообщения не удается он будет либо перейти в очередь назначения исключения, или если установлено значение None повторит попытку после определенного количества времени, которое установлено на уровне шины, но может быть переопределен для каждого назначения (см. переопределение messaging engine заблокирован повтор тайм-аут по умолчанию)
Я не знаю, нужно ли вам это, но вы должны проверить пользовательское свойство:
sib.processor.blockedRetryTimeout
определено для механизма обмена сообщениями.
это то, что вы ищете, в то время как сообщение ждет повторной доставки, оно находится в состоянии разблокировано и может быть отброшено соответственно.