1

セッションに保存しているオブジェクトは、LocalizationContextシリアル化できない で、Tomcat は 5.5.28 ですが、qa サーバーは Tomcat 5.5.30 です。これはTomcatのドキュメントからのものです：

Catalina が正常にシャットダウンされて再起動されるとき、またはアプリケーションのリロードがトリガーされるときはいつでも、標準の Manager 実装は、現在アクティブなすべてのセッションをパス名属性を介して配置されたディスク ファイルにシリアル化しようとします。このように保存されたすべてのセッションは、アプリケーションのリロードが完了すると、デシリアライズされてアクティブ化されます (その間に有効期限が切れていないと仮定します)。

セッション属性の状態を正常に復元するには、そのようなすべての属性が java.io.Serializable インターフェイスを実装する必要があります。<distributable>この要素を Web アプリケーションのデプロイメント記述子 (/WEB-INF/web.xml) に含めることで、Manager にこの制限を適用させることが できます。

これにより、私のローカルでも問題が発生するはずであり、実装しない限り、Tomcat にセッション属性を保存することはできないと思いますSerializable。

編集：

申し訳ありませんが、より明確にするために、私の質問は2つあります。すべてのセッション属性はシリアライズ可能である必要がありますか? もしシリアライズ可能であるなら、ローカル環境で引き続き機能するのはなぜですか?

4

1 に答える 1

8

特にユーザー セッションを永続化して後で復元できる環境向けに開発する場合は、セッション属性 (したがってセッション) がシリアル化可能であることが望ましいです。これは多かれ少なかれ、クラスター内のセッションのフェイルオーバー/移行の前提条件です。

ただし、セッションがシリアル化されるシナリオはクラスタリングだけではありません。単一のコンテナでは、コンテナがシャットダウンされているときにセッションを永続化でき、コンテナが再び戻されたときにシリアル化解除されます。もちろん、これはコンテナーのサポートに依存し、Tomcat を含む多くのコンテナーがこの機能をサポートしています。

ローカル環境でエラーが発生しない理由についての合理的な答えは、セッションをシリアル化しようとしたときにのみエラーにフラグが立てられるということです。コンテナーには、セッション内の属性値がシリアライズ可能かどうかのチェックは含まれません。コンテナはこのチェックを実装しません。結局のところ、このようなテストにはセッションの実際のシリアライゼーションが含まれますが、これにはパフォーマンスが集中する可能性があり、プログラミングのミスを防ぐという唯一の利点があります。

于 2010-08-11T16:24:59.443 に答える