1

я получил этот случай использования:Каков наилучший способ справиться с исключением из java MDB?

Эта диаграмма представляет модель предприятия. Технология Java EE на Weblogic 10.3 с использованием пружинного каркаса для IoC и АОП, JPA для сохранения с пружинной jpatemplate, интеграция пружин для кадра взаимодействия. Как вы можете видеть, нет связи между Сервисом и Шлюзом, так как весенняя интеграция добавляет весь необходимый магический сахар.

Теперь мне приходится иметь дело с обработкой исключений. Вся цепочка не имеет проверенных исключений: также доступ к данным не имеет проверенного исключения, поскольку jpatemplate обертывает все исключения sql в исключениях времени выполнения.

Так проверяется только исключение, которое я обрабатывать находится на MDB

@Override 
    @TransactionAttribute(TransactionAttributeType.REQUIRED) 
    public void onMessage(Message message) { 
     try { 
      TextMessage textMessage = (TextMessage) message; 
      String stringMessage = textMessage.getText(); 

      OnlineEventMessage<? extends Serializable> event = eventMessageParser.parse(stringMessage); 

      legacyEventMessageService.handle(event); 
     } catch (JMSException e) { 
      logger.error("si e' verificato un errore JMS nel processamento dell'evento {}", message, e); 
     } 
    } 

Я заметил, что если я получаю NPE, например, на какой-то компонент цепи сообщения откатывается на очереди JMS а процесс зацикливается.

Каков наилучший способ обработки исключений в этом сценарии? Поймать все runtimeExceptions в MDB?

Сердечные приветы Massimo

ответ

1

Что является лучшим способом для обработки исключений в этом случае? Поймать все экземпляры runtimeException в MDB?

Это зависит от того, чего вы хотите достичь. Если вы чувствуете от своего описания, что хотите предотвратить откат сообщения. Это правильно?

В этом случае перехват всех исключений во время выполнения получает вас только до сих пор. Система также может выдавать ошибки, которые вы не поймаете. Таким образом, вы должны поймать Throwable. Но тогда транзакция все равно может закончиться, что приведет к откату.

Одним словом, вы хотите, чтобы ваш MDB был транзакционным?

Также обратите внимание, что контекст транзакции от отправителя не распространяется на MDB.

Немного от темы, но вы действительно уверены, что вам нужна jpatemplate? Похоже, что все согласны с тем, что JPA API сам по себе хорош и не нуждается в каких-либо «улучшениях» от Spring, включая самого SpringSource.

+0

Я заметил ваш комментарий в связи с темой, и мне было интересно, что такое компромисс с использованием jpa вместо jpatemplate. –

+1

В отличие от некоторых других API, которые много полезны или, по крайней мере, немного от шаблонов Spring, JPA API уже является хорошо разработанным и современным API. Компромисс с использованием jpatemplate заключается в том, что вы используете другой API, который не нуждается в API. Я не могу придумать преимуществ, и поэтому это не похоже на компромисс. –