次の質問が頭に浮かびます
1) どこかで読みました:
パッシベーション: ステートフル Bean のスケーラビリティの可能性
ここでスケーラビリティとはどういう意味ですか?
2) ステートレス セッション Bean は、ステートフル セッション Bean よりもどのようにスケーラブルですか?
3) として
パッシベーションの場合、ステートフル セッション Bean がシリアル化され、アクティブ化の場合、コンテナーによって逆シリアル化されます ...
なぜシリアライゼーションとデシリアライゼーションが必要なのですか?シリアライゼーションとデシリアライゼーションなしではそれ(パッシベーションとアクティベーション)を行うことはできませんか? そして、シリアライゼーションがコンテナーが Bean をパッシベートするのにどのように役立つのですか??
1) ステートフル セッション Bean は、メソッド呼び出し間で ID と状態を維持する必要があります。そのような Bean がしばらくアクセスされていない場合、コンテナーはそれを非活性化することを選択できます。これは、その状態が何らかの方法で JVM の外に保存され (通常、Java シリアライゼーションを使用してディスク ファイルに書き出される)、そのリソース使用量 (メモリ) が回復されることを意味します。コンテナは、SFSB が再びアクセスされると、コンテナを再度アクティブ化 (デシリアライズ) します。したがって、SFSB はより適切にスケーリングできます (1 つの JVM に収まる「インスタンス」が増えるが、関連する時間と I/O のペナルティがあります)。
2) ステートレス Bean は、単一のメソッド呼び出しの間のみ存在する必要があり、その後、それらが使用するリソースを再利用できます。より一般的には、それらのいくつかはプールに維持され、特定のメソッド呼び出しを処理するために一時的に利用可能になります。そのため、ステートレス セッション Bean は、スケーラビリティにほとんどまたはまったく直接的な影響を与えません。
ステートフル セッション Bean は、ステートレス セッション Bean とはまったく異なる目的で使用されます。スケーラビリティの問題があるため、どちらか一方を選択することはありません。
3) シリアル化は、Java が任意のオブジェクト状態を読み書きするために使用するメカニズムです。SFSB に関連付けられたインスタンス変数は、シリアライズ可能でなければなりません (いくつかの文書化された例外は別として)。これにより、SFSB を非アクティブ化/アクティブ化できるだけでなく、フェイルオーバーや負荷分散をサポートするために、SFSB を他の JVM インスタンスに移行することもできます。
SFSB に関しては、パッシベーションとアクティベーションは別の方法で行うこともできますが、シリアライゼーションは EJB 仕様で義務付けられています。