@テオ:素晴らしい。したがって、基本的に現在のビジネスフローは次のとおりです。
フロントエンド (JSF UI) 操作 --> EJB 層 (トランザクション開始) ---> メッセージを FINAL QUEUE にパブリッシュします。
ここで、問題を解決する 1 つの方法を示します:- 間に分割キューを定義できます:- したがって、フローは次のようになります。
次のいずれか:- フロントエンド (JSF UI) 操作 --> EJB レイヤー --> SPLIT QUEUE ---> MDB --> FINAL QUEUE
または、フロントエンド (JSF UI) 操作 --> SPLIT QUEUE ---> EJB 層 --> FINAL QUEUE
したがって、基本的な考え方は、トランザクション制限ごとに n 個のメッセージ送信者があり、公開するメッセージが m 個ある場合、m>n および m>0 であるためです。次に、途中で SPLIT QUEUE を導入することにより、m をブロックに m\n 回分割できます。私はプロジェクトの1つでこれを行いました。ご不明な点がございましたら、お知らせください。
@Theo:Asynkronosが言及したことはよくわかりません。しかし、ここで私が言いたいことは次のとおりです。- JSF UI 操作の結果、FINAL キューへの 1000 の JMS メッセージが (たとえば) 送信されます。ここで、トランザクションごとに 200 の JMS メッセージの制限があるとします。あなたができることは次のとおりです:-
あなたのデータモデル/ビジネスフローは完全にはわかりませんが、概要は次のとおりです。JMS メッセージのペイロード データが、識別子 Un によって一意に識別できる一連のテーブルから来ていると仮定しましょう。したがって、U1,U2....U1000 で識別されるパブリッシュされる JMS メッセージが 1000 あります。基本的に、内部 SPLIT キューを定義できます。Java コードで、1000 個の識別子をそれぞれ 200 個のブロックに分割します。つまり、{U1...U200}、{U201....U400)、{U401...U600)、(U601、..U800) および (U801) 、...U1000)。これらの識別子のリストを Java.util.List ペイロードとして分割キューに発行できます。トランザクション属性 REQUIRES-NEW を使用して、MDB リスニング SPLIT キューを定義できます。MDB コードでは、識別子のリストを取得して for ループを実行できます。
onMessage(Message m){
ObjectMessage objectMsg=(ObjectMessage) m;
java.util.List list=(List) objectMsg.getObject();
//open a JMS session
for (String identifer : list){
//fetch data from DB for particular identifier.
//prepare output JMS payload for that particular identifier.
//publish JMS data onto FINAL queue
}
これが明確になることを願っています。