Tomcat（ここではバージョン5）はセッション情報をメモリに保存します。この情報のクラスタリングは、クラスタ内の他のサーバーに定期的にブロードキャストされ、同期が維持されます。データベースストアを使用してセッションを永続化することはできますが、この情報は定期的に書き込まれるだけで、実際にメモリ内セッションを置き換えるのではなく、障害回復に実際に使用されます。Tomcatとは別のセッションストアを指定する方法はありますか？
スティッキセッションを使用したくない場合（私たちの設定では残念ながら許可されません）、セッションが同期しなくなる問題が発生します。
他の言語では、Webフレームワークではデータベースをプライマリセッションストアとして使用できます。これによりスケーリングの問題が発生しますが、セッション管理は非常に簡単です。私は、この方法でセッション用のデータベースを使用する方法があるかどうか疑問に思っています（技術的にはTomcat server.xmlのクラスタリング設定の必要性もなくなります）。
間違いなく方法です。スティッキーセッションに強く投票しますが、サーバー/データベースの負荷を節約できます（何かが失敗しない限り）。
http://tomcat.apache.org/tomcat-5.5-doc/config/manager.htmlには、Tomcat用のSessionManager構成とセットアップに関する情報があります。厳密な要件に応じて、独自のセッションマネージャを実装する必要があるかもしれませんが、この出発点には何らかの助けが必要です。
Terracottaを見てください。大きなアプリケーションの再設計なしにスケーリングの問題に対処できると思います。
私はいつもRailsのセッションテクニックのファンでした。ユーザーのクッキーにセッション（zipped + encrypted + signed）を保存します。あなたの心のコンテンツにロード・バランシングを行うことができ、セッション・データなどのためにデータベースに当たったり、スティッキー・セッションを心配したりする必要はありません。あなたのセッションアクセスコードの書き直し。とにかくちょっと考えました。
もう1つの方法は、tomcat 6.x/7.xのmemcachedベースのセッションフェイルオーバーおよびセッションレプリケーションソリューションのmemcached-session-managerです。これは、スティッキーセッションと非スティッキーセッションの両方をサポートします。
パフォーマンスと信頼性を最大限に引き出し、さらにtomcatとmemcachedノードを追加するだけでスケールアウトできるように、このプロジェクトを作成しました。
スティッキーセッションを使用しない場合、同じセッションの要求が同じJVMから提供されるというサーブレット仕様の要件の1つを破ります。 Tomcatはこれを非常に難しくします。おそらく、セッションをデータベースに保存することで失われたアップデートの問題が発生するでしょう。 – davidsheldon