PoEAA ch17 Server Session State
Server Session State
Keeps the session state on a server system in a serialized form.
How It Works
- 最も単純な形としては、アプリケーションサーバのメモリ上にセッションオブジェクトを持つ
- 前提
- サーバが十分なメモリを積んでいる
- アプリケーションサーバは1台である
- クラスタリング、fail-overなし
- 唯一のアプリケーションサーバが落ちたら全てのセッション情報が失われる
- 上記前提が崩れる場合は、もう少し複雑なパターンを導入することになる
- メモリ容量問題
- セッション情報をどんな形にシリアライズする
- テキスト
- XMLとか
- バイナリ
- テキスト
テキスト | バイナリ | |
---|---|---|
コード量 | 多少は必要 | ほとんど不要 |
human-readable | yes | no |
サイズ | 大 | 小 |
バージョニングの問題 | なし | あり |
- バイナリの場合、デシリアライズ先のクラスに変更・更新が加わるとデシリアライズ不可能になる
- フィールドが1つ追加されたらもう駄目
- 困ることはレアケース
- 例: 無停止システムをクラスタリングしていて、アップデート時に新旧クラスが混在する場合など
- セッション情報をどこに永続化する
- アプリケーションサーバ自身
- 外部の共通サーバ
- 特に2Cのサービスの場合、ごみ掃除が必要
- 今日び(本書執筆当時)では、アプリケーションサーバ自身が自動的にセッションをサポートしてくれたりする
- クラスタリングやfailoverをサポート
Java Implementation
- 略
.NET implementation
- 略
When to Use It
- Session State系パターンの中で最もシンプル
- たいていのケースにおいて、プログラミングほぼ不要
- クラスタリングやfailoverが...
- 不要な場合、単にメモリ上オブジェクトで済ます
- 必要な場合、セッション情報を外部サーバに出すが、アプリケーションサーバがよろしくやってくれる
- クラスタリングやfailoverが...
- 自分で外部DBにセッション情報を出すにしても、データを表型に変換する(Database Session State)よりもSerialized LOB(Server Session State)のほうが楽
- たいていのケースにおいて、プログラミングほぼ不要
- クラスタリングやfailoverをサポートするために自前実装が増えると、他のパターンより苦労するかも
- 下記のような場合、他のパターンを検討する
- セッション情報が少量
- 【補】Client Server Stateパターンが適する
- データを容易に表型に変換できる
- 【補】Database Server Stateパターンが適する
- セッション情報が少量
- 下記のような場合、他のパターンを検討する
英語
- passivate/activate
- サーバーのクラスタリング界隈の言葉
- contention
- 競合
- unceremoniously
- 突然
- 突然ログインが切れる、といった文脈
- 突然