正直なところ、
「SessionをInProcで利用してはいけない。」
というのは、誰もが知っている常識だと思っていたが、最近、仕事の中で案外そうでもない事に気づかされたので、あらためて解説します。
解説するのは以下の２点
１．なぜInProcで管理してはいけないのか。
２．どのタイミングでInProc以外にするべきなのか。
です。
まず最初に、「１．なぜInProcで管理してはいけないのか。」について解説します。
ASP.NETのプロセスは、ある条件（IISにて設定できる。経過時間だったり、特定の時間だったり、消費メモリ量だったり）に基づいて自動的に再起動するようになっています。
再起動するということは、プロセスに保持していた内容も最初からという事になります。
ということは、InProc(SessionをASP.NETのプロセス内で管理する。)だと、Sessionの内容が消去されてしまいます。
その仕組みを知らないままだと、知らないがゆえの原因不明のバグ（突然セッションの内容が消えた等・・・）に悩まされることになります。
特に開発時は発生しないためそのままリリースしてしまい、運用に入ってから突然発生して驚かされるという事になります。
そのため、SessionのモードはInProc以外(StateServerやSQLServerを利用して、プロセス外に保持するようにする。)を適用するようにしたいところです。
では続いて、「２．どのタイミングでInProc以外にするべきなのか。」について解説します。
最初に結論から述べると、
「開発の初期から。つまり最初から。」
となります。
ではなぜ最初からInProc以外にする必要があるのでしょうか。
それは、以下の２点
１．InProc以外のモードはシリアライズ可能なオブジェクトしか管理できない。
２．InProc以外のモードはSessionのEndイベントが発生しない。
について、InProcとそれ以外のモードでは動作が違うからです。
そのため、最初からInProc以外のモードを前提として開発していないと、いざ運用に入ってから
「シリアライズ可能じゃないから、セッションで管理できない。」
といった、例外が発生して、大幅な手戻り（セッションで管理しているオブジェクトがシリアライズ可能になるようにしなくてはいけない。）が発生する可能性や
「SessionのEndイベントが発生する前提で設計してしまった。」
といった事態が起きて設計の変更という手戻りが発生するが出てきます。
本来、最初からInProc以外のモードを前提としていれば、発生しない手戻りなわけです。
以上の事からも、
「運用時に利用するセッションのモードで最初から開発を行うべき。」
だという事が言えます。
今更感のあるエントリですが、あらためて解説してみました。
