JavaEE環境でのセッションのシリアライズ
次のシナリオを検討してください。
現在、スケーラビリティが問題になり始めているJavaEEプロジェクトに取り組んでいます。今まではスケールアップできましたが、これはもはやオプションではありません。したがって、クラスター環境向けにアプリをスケールアウトして準備することを検討する必要があります。
現在の主な関心事は、ユーザーセッションのシリアル化です。悲しいことに、この問題を最初から考慮していなかったため、次の例外が発生しています。
_Java.io.WriteAbortedException: writing aborted; Java.io.NotSerializableException: org.Apache.catalina.session.StandardSessionFacade
_調査を行ったところ、Serializableインターフェースを実装していないオブジェクトがセッションに格納されているため、この例外がスローされます。アプリ全体に、このインターフェイスを実装せずにセッションに保存されるカスタムオブジェクトがかなりあることを考えると、これらのクラス宣言をすべて修正するには、多くの面倒な作業と献身が必要になります。
このすべての宣言を修正しますが、主な懸念は、将来、セッションにSerializable以外のオブジェクトを追加し、複数のノードでのセッションのシリアル化とレプリケーションを中断する開発者が存在する可能性があることです。
プロジェクトの簡単な概要として、サーブレット3.0 APIを備えたStruts 1に基づく自作のフレームワークを使用して開発しています。つまり、この時点では、標準のsession.getAttribute()とsession.setAttribute()を使用してセッションを操作しており、セッション処理はコードベース全体に分散しています。
セッションに格納されたオブジェクトのクラスを更新し、それらがSerializableインターフェイスを実装していることを確認する以外に、アプリケーションレイヤーで信頼できるセッションレプリケーション機能を確保するために、他にどのような対策を講じる必要がありますか？これを検討するのは少し遅いのですが、この場合のベストプラクティスは何でしょうか。さらに、この移行に関して私たちが考慮すべき他の問題はありますか？
前もって感謝します！
セッションが複製された、スケールアウトされたクラスター環境のみを検討している場合は、回避策はありません。すべてのオブジェクトはシリアライズ可能でなければなりません。
しかし、アプリケーションとJava EEアーキテクチャでスケールアウトされた「クラスタ化された」環境を実行できる場合複製されたセッションなしであれば、問題ありません。ユーザーがログインして別のサーバーにリダイレクトする機能は、ユーザーが何らかの理由でシャットダウンしていた場合にシャットダウンされます。このユーザーは別のサーバーにリダイレクトされる可能性がありますが、再度ログインする必要があります。アプリケーションは十分にスマートではありません、彼/彼女は彼らが何をしていたかをもう一度やり直す必要があります。
オブジェクトがシリアライズ可能であることを本当に確認できない場合は、「非クラスター化」のロードバランスを検討してくださいJava EE Webコンテナー（EJBは引き続きクラスター化されている可能性があり、スケーラビリティが向上する可能性があります）スティッキーセッション複製されないHttpSession。