セッションとは？
|
ASP.NETのページを記述したaspxファイルの実行を終えて、レスポンスとして送信されるWebページが完成してしまえば、実行時の状態（変数の値）はすべて破棄されてしまうのが基本だが、Sessionプロパティに格納された値だけは別だ。ここに格納された値はレスポンスを生成し終えた後もサーバ上に保存され、次回ポストバックされたときに再び参照できるようになる。もちろん、Sessionプロパティに直接格納された値だけでなく、そのプロパティから参照されている値も破棄されずに保存される。 Sessionプロパティは、Pageクラスのメンバとして宣言されたHttpSessionStateオブジェクトである。このプロパティはディクショナリ形式のコレクション・オブジェクトであり、＜キー＞と＜値＞のペアを複数登録できる。キーはstring型、値はobject型である。格納する値オブジェクトのデータ型に制限はない。値の登録時には、キー（以下の例では"username"）をインデクサに指定して、値を格納する。値の参照時には同じくキーを指定して、ペアの値を取り出す。なお、Sessionプロパティに格納される値はobject型なので、取り出した値は適切にキャストして利用する。 いったんSessionプロパティに格納された値は、セッションが終了するか、タイムアウトするか、明示的に削除されるまで、何度ラウンド・トリップしても破棄されることはない。 Sessionプロパティを利用したサンプル・プログラムをリスト15.1に示す。リスト15.1ではSessionプロパティに変数counterの値を保存して、ポストバックするごとにカウントアップされるカウンタを実現している。 すでに何度も述べているように、ラウンド・トリップを終えるとサーバ上からほとんどの情報は破棄されてしまう。そこでSessionプロパティが用意されているわけだが、このプロパティはセッションに対してプライベートに管理されているため、複数セッションが同時に進行中の場合、サーバ上には複数のSessionインスタンスが存在していることになる。従って、次にポストバックしたとき、どのSessionインスタンスへアクセスすればいいのか、識別するためのセッションIDが必要になる。 このセッションIDは、通常クッキーに保存される。ASP.NETページへアクセスすると、120bitからなるセッションIDが暗黙的に発行され、例えば以下のようなデータがHTTPヘッダを通して、クライアントへと送信される。 このクッキーはクライアントのメモリ上に保存されるが、ディスクへは書き込まれないため、ブラウザを閉じてセッションを終了すれば、クライアント上から破棄されてしまう。そうなれば、このセッションIDに対応付けられていたSessionインスタンスへアクセスする手段はなくなり、タイムアウトを待つだけとなる。 ASP.NETアプリケーションのセッションは、こうしてクッキーを利用して管理されているため、クッキーをブロックしてしまうユーザーの場合、クッキーが保存されないので、ポストバックするたびに異なるセッションIDが発行されてしまい、セッションを継続できなくなってしまう。Sessionプロパティに値を保存しても、次のポストバックを行ったとき、その値を参照できないということだ。例えば、リスト15.1の場合ならば、何度[up]ボタンをクリックしても、カウンタの値は0のままとなる。 もしこうしたユーザーに対してもセッション管理を行いたければ、クッキーを使わず、代わりにセッションIDをURLに埋め込む方法が提供されている。この方法を使うと、ASP.NETアプリケーションへアクセスしたときに、以下のようにURLがセッションID（この例では“4loltr453qe01sadabumak55”）を含むように置換され、セッション管理が行われる。 このクッキーレス・モードを利用したセッション管理を行うには、以下のweb.configファイルをアプリケーション・ルート（仮想ディレクトリとして指定したディレクトリ）に作成するだけでよい。コードの修正は必要ない。 すでに解説したとおり、Sessionプロパティに格納された値には有効期限が設定されており、これを過ぎると自動的に破棄されてしまう。この有効期限はデフォルトで20分に設定されているが、サーバ・リソースを節約するためにもっと短い有効期限を設定することもできる。 Sessionプロパティの有効期限は、クッキーレス・モードの設定と同じく、web.configファイルのsessionState要素で行う。このtimeout属性に分単位で指定した値がセッションの有効期限となる。例えば、リスト15.3に示すweb.configならば、セッションのアイドル状態が10分継続した時点でタイムアウトとなり、セッションが破棄される。 なお、タイムアウトしてもセッションIDは再発行されず、同じ値のまま継続して利用されるが、Sessionコレクションは空になるので、どのキーでアクセスしても値はnullとなる。 通常、セッション情報はASP.NETアプリケーションを実行するワーカー・プロセス（IIS本体ではなく、実際にアプリケーションを処理するプロセス）内部に保存されているが、より高レベルなサービスを提供するために、ステートサーバと呼ばれる、プロセス外にセッション情報を保存する手段が提供されている。 ステートサーバを利用するメリットは、信頼性の向上にある。ステートサーバはIISから独立したプロセスとして実行されるため、ワーカー・プロセスが誤動作したり、IISを再起動したりしても、ステートサーバに保存されたセッション情報が失われることはない。もちろん、その瞬間にアプリケーションが起動されていたセッションは正しいレスポンスを返すことはできないだろうが、ユーザーからのポストバックを待っていたセッションは、IISさえ正常に戻れば、そのまま何食わぬ顔で処理を継続できる。 また、IISとステートサーバは、ネットワーク接続さえされていれば、同一マシン上に存在していなくても構わない。従って、Webファーム（クラスタ化されたWebサーバ群）に対して、独立したステートサーバを1台用意する構成を取れば、1台のWebサーバに障害が発生しても、残りのWebサーバがセッションを継続できる（ステートサーバがウイークポイントとなってしまうが）。 パフォーマンスでは通常のインプロセス・モードに分があるが、信頼性を優先させるならば、ステートサーバ・モードの利用を検討するとよいだろう。 ステートサーバ・モードを利用するにあたって必要な作業は、ステートサーバを起動し、以下に示すweb.configファイルを用意することだけだ。アプリケーション・コードに修正は必要ない。web.configファイルでは、sessionState要素のmode属性に"StateServer"を、stateConnectionString属性に「tcpip=＜ステートサーバ・マシンのIPアドレス＞:42424」を設定すればよい。 ステートサーバは「ASP.NET State Service」の名前でサービスとして登録されているので、サービス・マネージャで起動する。 サービス・マネージャはコントロール・パネルの［管理ツール］−［サービス］で実行することができる。ステートサーバはWindowsサービスとして動作する。 なおここでは割愛するが、セッションの情報はSQL Serverによりデータベースで管理することも可能だ。 Google対抗？ Microsoft Sync Frameworkの正体 （2007/11/20） 先日、マイクロソフトが発表した同期フレームワークは、.NETアプリケーションに何をもたらすのか？ 実装サンプルを通して、その機能と特徴を簡単に紹介 ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠ITトップ｜Insider.NETフォーラム トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
[ 80] ＠IT：連載：プログラミングASP.NET 第15回 セッションとビューステート
[引用サイト] http://www.atmarkit.co.jp/fdotnet/aspnet/aspnet15/aspnet15_02.html
