長時間実行されるバッチ タイプのジョブを開始する必要があります。長い間、数時間かかる可能性のあるジョブについて話しています。この長時間実行されるジョブを実行するロジックを持つ ejb は、NoSQL ストアと通信し、データなどをロードします。
そのため、JMS MDB を使用してこれを非同期的に実行しています。ただし、各ジョブには最大 1 時間以上かかる可能性があるため (最大 4 時間と仮定します)、MDB の onMessage() メソッドをそれほど長く待機させたくありません。そこで、onMessage() MDB メソッド内で非同期 ejb を起動して、バッチ ejb ランナーへの呼び出しの直後に MDB をプールに戻すことを考えていました。
非同期の ejb メソッド呼び出しを MDB と組み合わせることは理にかなっていますか? ほとんどのサンプルは、どちらか一方を使用して同じことを達成することを提案しています。
MDB から呼び出される ejb が非同期でない場合、MDB は長時間待機する可能性があります。
お知らせ下さい。
@Schedule を使用して @Asynchronous を呼び出し、JMS のことは忘れてください。うまくいかないことが 1 つ少なくなります。
JSR 352: Batch Applications は、まだ準備ができていませんが、この種のものには非常に有望です。
https://blogs.oracle.com/arungupta/entry/batch_applications_in_java_ee
それは好みの問題だと思います。
JMS プールからのスレッドでジョブを実行している場合、または非同期 ejb でジョブを実行している場合、最終結果は同じになります。スレッドは一部のプールからブロックされます。
MDB から非同期 Bean を生成しても問題はありません。ジョブをメッセージング インターフェイスによってトリガーする必要があるかもしれませんが、スレッド プールをブロックしたくない場合があるからです。また、トランザクションはデフォルトでは 1 時間前にタイムアウトすることが多いため、何らかの理由で MDB トランザクションを実行する場合は、onMessage 内でその非同期 ejb の起動を検討することをお勧めします。
ペッターがほとんどの質問に答えていると思います。非同期動作を取得するためにのみ mdb を使用している場合は、@Asynchronous asap を起動するだけです。
ただし、JMS 実装が信頼性、永続的なキュー、遅いコンシューマー ポリシー、ジョブの優先度などの点で提供する他の機能に興味がある場合は、mdb:s に固執する必要があります。
ejb 3.1 で @Asynchronous を導入した理由の 1 つは、他の JMS/MDB 機能が不要な場合に、非同期処理を実行するためのより軽量な方法を提供することです。