Java EE (OC4J 10) 環境でバックグラウンド プロセスを開始したいと考えています。「新しいスレッド」でスレッドを開始するのは間違っているようですが、これには良い方法が見つかりません。
このメソッド呼び出しのパラメーターはシリアル化できないため、私の特殊なケースでは JMS キューを使用するのは困難です。
セッション Bean でタイマー メソッドを使用することも考えonTimeoutましたが、これではパラメーターを渡すことができません (私の知る限り)。
そのようなタスクを処理する「標準的な」方法はありますか、それとも「新しいスレッド」またはjava.concurrent.ThreadPool.
Java EE は通常、開発者の関心からスレッド化を取り除こうとします。（これでの成功はまったく別のトピックです）。
JMS は明らかに、これを処理するための推奨されるアプローチです。
ほとんどのパラメーターでは、既定でシリアル化できない場合でも、シリアル化を強制または偽造するオプションがあります。データによっては、データを再ロードできるシリアル化可能なオブジェクトにラップすることを検討してください。これは明らかにパラメータとアプリケーションに依存します。
JMS は、これを行う Java EE の方法です。コンテナーで許可されている場合は、独自のスレッドを開始できますが、それは Java EE 仕様に違反しています (これを気にする場合と気にしない場合があります)。
Java EEの一般的なコンプライアンスを気にしない場合(実際にJMSを扱うのではなくスレッドに頼る場合)、Oracleコンテナにはこれを行うための独自の方法があります( OracleAS Job Schedulerなど)。
OCJ4 の詳細はわかりませんが、Thread アプローチと java.util.Timer アプローチを使用して、Tomcat ベースのアプリケーションでいくつかのタスクを実行しました。Java 5+ では、Executor サービス (Sheduled、Priority) のいずれかを使用するオプションがあります。
onTimeoutについてはわかりませんが、セッション自体、アプリのコンテキスト、または静的変数でパラメーターを渡すことができます（お勧めしないと言う人もいます）。しかし、名前は、ユーザーのセッションがタイムアウトしたときに呼び出され、クリーンアップを行いたいことを示しています。
JMS を使用するのが正しい方法ですが、重量が重くなります。
得られる利点は、複数のサーバー、1 つのサーバー、またはその他のサーバーが必要な場合、サーバーを構成すると、「スレッド化」を複数のマシンに分散できるようになることです。
また、本当に些細な量の作業や大量のデータを伴うメッセージを送信したくないことも意味します。インターフェイス ポイントを適切に選択します。
詳細については、こちらを参照してください。
問題なくコンテナー (Tomcat、JBoss) にスレッドを作成してきましたが、それらは本当に単純なキューであり、クラスタリングには依存していません。
ただし、EJB 3.1 では、役に立つと思われる非同期呼び出しが導入されます 。