EJBのスレッドとスレッド

Question

私は、EJBのライフサイクルを妨げる可能性があるので、EJB内からスレッドを生成することは不正だと思っています。しかし、EJB内のExecutorなどのスレッドを内部的に生成して処理する、JDKの事前定義Javaクラス、特にMDBを使用するのは不正ですか？

Answer 1

スレッドとEJBの最大の問題は、スレッドがコンテナによって頻繁に使用される限られたリソースであり、スレッドの間違いによってスレッドプールリークが発生し、JVMインスタンス全体が効果的に消滅することです。

実行者はとなるはずですが、それでもなおある程度の時間スレッドを使い果たしてしまいます。また、誰かが使用可能なスレッドを使い果たすようにコンテナをチューニングした場合、ただちに失敗することもあります。

要約すると、あなたは綱渡りをするでしょう。

Answer 2

@Charlie Martinの答えに追加するには、Executorに必要なものがあれば、別のEJBを設計してExecutorなしで同じアクションを実行することができます。これにより、新しいEJBがコンテナによって処理される別のスレッドで実行されるようになります。欠点は、JVMからスレッド/ Executorを使用したくないため、「ホイールを再実装する」必要があるかもしれないことです。また、1つのEJBが別のEJBを見つけたり、要求したり、接続したり、別のEJBを呼び出すためのオーバーヘッドが増えます。

結論として、EJBはワーカースレッドそのものであるはずです。エグゼキュータを使用せずにコードを複製することは過度に思えるかもしれません。最も大きな違いは、スケールの1つです。エグゼキュータは1つのJVMに制限され、EJBはJVM間およびサーバー間で拡張できます。

Answer 3

スレッド、スレッドプール、エグゼキュータなどは使用できません（すべきではありません）。アプリケーションサーバーを使用するポイントは、ビジネスロジックを記述し、アプリケーションサーバーに重い作業をさせることです。独自のスレッディングを本当に必要とする場合は、スレッド3.1を管理するためにEJB 3.1の "シングルトン"サービスを使用してください。しかし、他の人に言われているように、これをアプリケーションサーバーに残すことが最善です。アプリケーションサーバーで並列処理を行う1つの方法は、並列処理のタイプによっては重すぎるかもしれないが、MDB（すでに使用しているように思える）を使用することです。

Answer 4

これは、EJB 3.1 @Asynchronousのためのものであり、エグゼキュータの代わりに使用する必要があります。一般的にコンテナのスレッドプールと競合することは非常に危険です。そうすることでパフォーマンスを低下させることができます。

Asynchronousサポートは、コンテナのスレッドプールを使用し、はるかに安全です。 Asynchronousの動作の詳細については、this answerを参照してください。