ASP.NET Webアプリケーションで、ユーザー情報はstatic変数ではなくてSession変数を使うこと

ASP.NET Webアプリケーションでは、ユーザー固有の変数は、staticではなくて、Session変数で保存すべきです。

static変数を使うのは、とても注意が必要です。

理由は次の通りです。

スポンサーリンク

Webアプリケーションでstatic変数を使うのは要注意!

たとえば、以下のサンプルアプリケーションがあったとします。

もし、2人のユーザーが同時にログインして、一人目が値を100にセットし、更に二人目がその値を200にセットしたとします。

一人目がこの後、Getボタンを押せば、結果は200となります。

static変数はユーザーを横断して保持されるために、Webアプリケーションでは注意が必要です。

上記のケースの場合、customerIDは次のようにSessionに保持されるプロパティとして定義すれば、あたかも、変数であるかのように扱えて便利です。

Session変数の更新は、InProcモードでしか反映されない

ASP.NETのセッションには以下の3種類あります。

  • InProc
  • StateServer
  • SQLServer

これらは、web.config の中の sessionState mode で指定します。

StateServerはwindowsサービス、SQLServerはDBという違いはありますが、両者ともにシリアライズ可能なオブジェクトのみ格納でき、InProcと違いワーカープロセスのリサイクル等でセッションは破棄されず信頼性も高いという位置づけです。

モード 管理 メリット デメリット
InProc ASP.NETワーカープロセス Webサーバメモリ上管理のため最速。
Session_OnEndイベントが発生する。
Webアプリケーション、ワーカープロセスのリサイクル等でセッション情報が失われる。
冗長構成にできない
StateServer ASP.NET状態サービス(aspnet_state.exe) Webアプリケーション、ワーカープロセスのリサイクルが発生してもセッションが保護される。
SQLServerよりは高速。
Webサーバと別サーバで動作可能
冗長構成にできない。
SQLServer SQLServer Webアプリケーション、ワーカープロセスのリサイクルが発生してもセッションが保護される。
冗長構成可能。
信頼性が最も高い。
3つの中では最も低速

Session変数を更新した場合、更新はInProcモードでしか反映されません。

http://stackoverflow.com/questions/16589578/asp-net-session-variables-update-by-thread-is-not-getting-reflected-in-session

StateServerモードの場合、Session変数を更新しても反映されない点は要注意です。

スポンサーリンク
スポンサーリンク
Translate »