MDBがメッセージを受信し、CMT/Requiredトランザクションで処理を開始し、トランザクションが完了するまでに時間がかかると仮定しましょう。MDBとDupeメッセージ
このようなシナリオでは、最初のトランザクションがまだ進行中の間に、別のトランザクションで別のMDBインスタンスが重複メッセージを受信して処理する可能性がありますか？
また、コンテナは、MDBがCMT/Requiredトランザクションでメッセージを処理している間に他のMDBインスタンスがその同じメッセージの塊を受け取らないようにしますか？
JMS仕様では、必要とするトランザクションの一部、および重複が、送信されてはならない間、私は、任意のメッセージをロックすることを期待する：メッセージの
4.4.15重複制作： JMSプロバイダの必須の重複メッセージを生成しません。つまり、メッセージを生成するクライアントの は、メッセージの コンシューマが一度だけ受信することを保証するためにJMSプロバイダに依存できます。
ので、私は、あなたが最初に明示的にロールバックされるか、またはトランザクションがタイムアウトし、暗黙的にロールバックされない限り、MDBがメッセージの2番目のコピーを受信しないことを確実にするために、メッセージング・プロバイダーに頼ることができると思います。これらの操作はどちらも、メッセージのロックを解除して、JMSRedeliveredをtrueに設定し、JMSXDeliveryCountを増分してMDBへの再配信に使用できるようにする必要があります。
EJB仕様、JCA仕様、JTA仕様（またはJ2EE）のうちの1つ（またはそれ以上）でJMS仕様を補う要件が増えていると思われます。
'4.4.15メッセージの重複生成：JMSプロバイダは決して重複メッセージを生成してはなりません。つまり、メッセージを生成するクライアントはJMSプロバイダに依存して、メッセージのコンシューマが一度しか受信しないようにすることができます.'これは 'AUTO_ACKNOWLEDGE'または一般的なものですか？ 'DUPS_OK_ACKNOWLEDGE'では、JMSプロバイダが二重引用符を送信できると思います。 MDBでは、すべての確認モードは無視されます。だから私はちょっと混乱している。 – CoffeeDriven
一般。 4.4.15は作業単位の範囲内でのみ適用される。トランザクションのロールバックが発生した場合、MDBにメッセージを複数回配信することは可能です。しかし、トランザクションが取り消されるまで、あなたは1つのコピーを得るだけです。 DUPS_OKに関しては、クラッシュが発生した場合には確認応答が記録されず、再起動後にメッセージが再配信される危険性があるため、遅延通知を行うことがプロバイダに示されます。 DUPS_OKを設定することにより、クライアントはこの方法で重複を気にしないと言っています。しかし、これはXA/MDBの場合には当てはまりません。 – strmqm
* 4.4.15 *はメッセージの**配信**ではなく、**制作**を指しています。 * 4.4.14 *では、自動確認モードで最後に消費されたメッセージが再配信される可能性があることに言及しています。 – CoffeeDriven