HttpServletがSerializableを実装するのはなぜですか?
-
05-07-2019 - |
質問
サーブレットの理解では、サーブレットはコンテナによってインスタンス化され、その init()
メソッドが1回呼び出され、JVMがシャットダウンするまでサーブレットはシングルトンのように動作します。
サーブレットがシリアル化されることは期待していません。アプリケーションサーバーが回復するか、正常に起動すると、サーブレットが新しく構築されるからです。サーブレットはセッション固有のメンバーを保持しないようにする必要があります。そのため、サーブレットをディスクに書き込んで再インスタンス化しても意味がありません。 これには実用的な用途はありますか?
私の懸念は、シリアル化できないフィールドをそこに置くと、異なる種類のセッション複製が行われる実稼働環境でアプリが不可解に失敗することです。
解決
技術的には、サーブレットコンテナは「パッシベーション」することが許可されていると思います。 EJBセッションBeanと同様の方法で、ディスクへのサーブレットオブジェクト。したがって、シリアル化できないフィールドが原因でアプリが失敗するかどうかを質問するのは正しいことです。
実際には、これを行うコンテナのことは聞いたことがありません。したがって、それは本当に初期のJ2EEの悪い昔からの単なる手荷物です。心配しません。
他のヒント
HttpServletはディスクにシリアル化され、サーブレットコンテナの再起動に耐える必要があります。たとえば、tomcatでは、この種の生存を可能にするフラグを設定できます。次のオプションは、JNDIを使用した転送です。これはゴミではなく、極端なユースケースでのみ使用されます。
Googleは、コンテナ作成者が必要に応じてオプションを選択できるように、これが行われたことを示唆しているようです。
サーブレットがセッション固有のメンバーを保持するべきではないというのは正しいことです。実際、可能な限り少ない状態を望んでいると思います。 SessionまたはServletConfigのいずれかにすべてを保存すると、シリアル化に耐えることができると思います。
クラスタオプションを提供するサーブレットコンテナのキャッシュを存続させるためにSessionオブジェクトがシリアル化されるように、コンテナがサーブレットインスタンスを別のクラスタノードに転送するオプションがあるかもしれません??ここで推測しているだけです
Serializableは、分散環境でセッションの属性のマーカーインターフェイスとして使用されます。
SRV.7.7.2分散環境(JSR-154)
配布可能とマークされたアプリケーション内で、 セッションの一部である1つのJava仮想マシンで処理する必要がある (“ JVM”)一度に。コンテナはすべてのオブジェクトを処理できる必要があります setAttributeを使用してHttpSessionクラスのインスタンスに配置されます またはputValueメソッドを適切に。以下の制限があります これらの条件を満たすために課された:
- コンテナは、Serializableインターフェイスを実装するオブジェクトを受け入れる必要があります。
- セッションの移行は、コンテナ固有の機能によって処理されます。
分散サーブレットコンテナは、 コンテナができないオブジェクトのIllegalArgumentException セッション保存の移行に必要なメカニズムをサポートする それら。
分散サーブレットコンテナは、必要なメカニズムをサポートする必要があります にとって Serializableを実装するオブジェクトの移行。
(...)
Container Providerは、スケーラビリティとサービス品質を保証できます 次の機能を備えているため、負荷分散やフェールオーバーなどの機能 セッションオブジェクトとそのコンテンツを、アクティブなノードから移動します システムの別のノードへの分散システム。分散されている場合 コンテナは、セッションを持続または移行して、 サービス機能、ネイティブJVMの使用に制限されない HttpSessionとそのシリアル化のためのシリアル化メカニズム 属性。開発者は、コンテナが呼び出すことを保証されていません セッション属性のreadObjectおよびwriteObjectメソッド それらを実装しますが、ただし、 その属性は保持されます。