他の人がいくつかの長所を指摘しているので、バックグラウンド プロセスを Web アプリと同じ jvm にデプロイする場合の短所を次に示します。
- Web モジュールを実行しているサーバーを開始および停止するということは、バックグラウンド プロセスを開始および停止することを意味します。これは、問題になる場合とそうでない場合があります。
- バックグラウンド プロセスが大量のメモリまたは CPU を消費する場合は、3 つのアプリケーションすべてとヒープを共有しており、Web アプリに影響を与える可能性があります。また、Web アプリが大量のリソースを消費する場合は、バックグラウンド プロセスに影響を与える可能性があります。
- Web アプリは、インターネット経由でアクセスできるようにデプロイする必要がある場合がありますが、バックグラウンド プロセスはネットにアクセスしなくても実行できる場合があります。必要がないのに、バックグラウンド プロセスをインターネットに公開する必要はありません。
- アプリ サーバー、フレームワーク、または構成をアップグレードするときは、3 つのことをテストする必要があります。バックグラウンド プロセスが独自に実行されている場合は、Web アプリとは別のリリース サイクルでアップグレードできます。
- コンテナーの外部でコードを開発およびテストする方が簡単です。コンテナー内でバックグラウンド プロセスを実行するということは、バックグラウンド プロセスの開発環境がより複雑になることを意味します。サーバーが起動するのを待つ必要があり、コンテナー リソースに依存して開始し、それから単体テストのフォームをモックする必要があります。
JPAはコンテナの内外で同じです。唯一の違いは、EntityManager を取得する方法です。これは、コンテナーの内外で同じになるように Spring で構成できます。CDI はコンテナーの外部で実行できる必要があります。
主な相違点は、Spring トランザクションと ejb トランザクションを使用するなど、db でトランザクションを行う方法です。
更新:
コメントから質問に答えるには: JPA では EntityManager はスレッド セーフではないため、Java EE サーバーでは、スレッドごとの永続ユニットごとに 1 つのエンティティ マネージャーが存在します。エンティティ マネージャーの作成と閉鎖は、アプリ サーバーによって管理されます。すべてのエンティティ マネージャにはキャッシュがあります。複数のエンティティ マネージャーにまたがる第 2 レベルのキャッシュを構成することができます。コンテナーの外部で実行する場合、JPA エンティティーマネージャーの数を自分で管理する必要があります。これは、バックグラウンドプロセスのスレッド数と必要なトランザクション境界によって異なります。「Pro JPA2」という本を見ると、コンテナの内部または外部での実行の詳細について説明しているセクションがあります。
私のアプリケーションにはバックグラウンド プロセスはありませんが、エンティティ マネージャーを必要とするすべてのクラスは、エンティティ マネージャーを使用して注入するだけで、Spring が@PersistenceContext EntityManager em;
すべてをコンテナーの内外で機能させるように処理します。Spring 3.1 にはプロファイルと呼ばれる機能があり、コードを 1 行も変更せずにコンテナーの外側で同じコードを簡単に実行できるようにします。私は CDI ユーザーではないので、CDI に spring 3.1 プロファイル機能と同等のものがあるかどうかはわかりません。