Каков наилучший способ обработки исключений в java MDB?

Я получил этот вариант использования:

На этой диаграмме представлена ​​модель предприятия. Технология Java EE в Weblogic 10.3 с использованием платформы Spring для IoC и AOP, JPA для сохранения с Spring jpatemplate, интеграция Spring для фрейма взаимодействия. Как видите, между Сервисом и Шлюзом нет никакой связи, поскольку весенняя интеграция добавляет весь необходимый волшебный сахар.

Теперь мне нужно разобраться с обработкой исключений. Вся цепочка не имеет проверенных исключений: также доступ к данным не имеет проверенного исключения, поскольку 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, и процесс зацикливается.

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

С уважением Массимо


java ejb-3.0 message-driven-bean exception-handling java-ee-5
person Massimo Ugues    schedule 28.01.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

Короче говоря, хотите ли вы, чтобы ваш MDB вообще был транзакционным?

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

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

person Arjan Tijms    schedule 29.01.2011
comment
Я заметил ваш комментарий не по теме, и мне было интересно, каков компромисс использования jpa вместо jpatemplate. - person Massimo Ugues; 03.02.2011
comment
В отличие от некоторых других API, которые во многом или, по крайней мере, немного выигрывают от шаблонов Spring, API JPA уже является хорошо разработанным и современным API. Компромисс при использовании jpatemplate заключается в том, что вы используете другой API, которому не нужен API. Я не могу думать о выгоде, и поэтому это не похоже на компромисс. - person Arjan Tijms; 04.02.2011