1

私はこのユースケースを得ました：

この図は、エンタープライズ モデルを表しています。Weblogic 10.3 上の Java EE テクノロジは、IoC および AOP 用の Spring フレームワーク、Spring jpatemplate を使用した永続性用の JPA、対話フレーム用の 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 ですべての runtimeExceptions をキャッチしますか?

よろしくマッシモ

4

1 に答える 1

1

このシナリオで例外を処理する最良の方法はどれですか? MDB ですべての runtimeExceptions をキャッチしますか?

それはあなたが何を達成したいかによります。説明から、メッセージがロールバックされるのを防ぎたいと感じた場合。そうですか？

その場合、すべてのランタイム例外をキャッチしても、これまでのところしか取得できません。システムはエラーをスローする可能性もありますが、その場合はキャッチできません。そのため、代わりに Throwable をキャッチする必要があります。ただし、トランザクションがタイムアウトし、ロールバックが発生する可能性があります。

要するに、MDB をトランザクション対応にしたいですか?

また、送信者からのトランザクション コンテキストが MDB に伝播されないことにも注意してください。

トピックから少し外れましたが、本当に jpatemplate が必要ですか? JPA API はそれ自体で十分であり、SpringSource 自体を含め、Spring からの「機能拡張」は必要ないことにほとんどの人が同意しているようです。

于 2011-01-29T10:22:18.227 に答える