Webレイヤ用のサーブレットとbizレイヤ用のejbs（2.0）を備えた従来のn層Webアプリケーションでは、サーブレットモデルをマルチスレッド化し、ejbモデルをシングルスレッド化する根本的な理由は何ですか？
つまり、すべてのリクエストに対して1つのサーブレットインスタンスしかありませんが、ejbsでは、リクエストごとに、Beanプールから割り当てられた新しいBeanインスタンスがあります。マルチスレッドサーブレット。 single threaded ejb
特定のServletのインスタンスは、ステートレスであると考えられるため、実際には1つのみです。実際には、これは必ずしもそうではありませんが、そうであってもかまいません。
ただし、Stateless session beans（SLSB）のインスタンスが複数あり、これらはプールされています。
非常に定義して、stateless session beansはステートレスなので、この表面でははのパラドックスのようです。物事は、stateless session beansは、個々の呼び出しに対して行われているステートレスですが、実際には非常に頻繁に状態があることです。
この状態は、の形で他のリソースへの参照です。 JPA entity managerはで、はスレッドセーフではありませんが、ここでは一番の例です。 stateless session beanへの1回の呼び出しでは、発信者はこのリソースに排他的にアクセスする必要があります。
1つのインスタンスが使用された場合、すべての発信者がお互いに待たなければならない（もちろん、パフォーマンスのために殺害されます）か、または呼び出しが返されると、次の発信者は排他アクセスを持つことができます。この単一インスタンスに同時にアクセスします。後者の場合、Beanの実装者は、多くの場合脆く、エラーが発生しやすく、最終的には呼び出し元がお互いに待つようになるentity managerのようなスレッドセーフではないリソースを手動でロックする必要があります。
したがって、パフォーマンスを向上させ、安全性を保証するために、複数のインスタンスが使用されています。
これらのインスタンスは、要求ごとに新しく作成されるのではなく、プールされ再利用されます。なぜなら、必要なすべての依存性の検索、初期化、および注入は潜在的に時間がかかるからです。
このように、エンティティマネージャやその他のスレッドセーフではないリソースをサーブレットに挿入すると、問題が発生する可能性があります。これは、Java EEアーキテクチャの小さなループホールです。もちろん、ステートレスセッションBeanを単純に使用するだけで簡単に処理できます。
通常、サーブレットは、EJBに実装されている重いロジックの薄いファサードを提供していると思います。サーブレットはステートレスでなければならないため、同じサーブレットのインスタンスを複数作成する必要はありません。
ステートレスBeanのみを使用している場合は、複数のインスタンスを持つ理由もないと思います。しかし、ステートフルなEJBは状態を持っているので、同時要求ごとにインスタンスが必要です。
私はうわべと言うつもりはないと思う。
SLSBには、JVMあたり複数のインスタンスがあります。インスタンス数は、Beanプール – Victor
で設定されています。技術的には、SLSBがEntityManagerにアクセスしていない場合は、マルチスレッド（つまり、1インスタンスのみ）にすることができますか？ – Victor
多かれ少なかれ。しかし、この場合、@Statelessアノテーションは使用しません** @Singletonを使用します。次に、EJB Beanのインスタンスは1つだけです。追加の注釈を使用して、複数のスレッドが（通常のサーブレットのように）そのようなEJBに同時にアクセスすることを許可するか、お互いに待機する必要があるかどうかを制御できます。 –