Recently we faced a scenario, where a piece of code in ASP.NET MVC application works fine in local development machine and same code fails to work in test environment. The code is pretty simple and can’t behave odd in test environment. During the troubleshoot process, we have decided to use in-proc session state in test environment instead of custom out-proc session state (App Fabric Session State provider to be specific), since this is the last difference we could see between local development machine and test environment. To our surprise this did in fact worked and same code works fine now in test environment after changing the session state mode to in-proc.
This interesting scenario raised a question, if there is any difference between in-proc session state and out-proc session state. After further analysis, it is identified that there is indeed a difference in the way complex objects are stored in in-proc session state and out-proc session state.
Lets consider an example to understand the difference better. In this example we have two classes named Employee and Address. Employee class has a property of type Address along with other string type properties.
When the objects (or instances) of above types is stored in session state using the lines of code depicted below, you may notice the difference between the memory layout of objects in In-Proc session state and Out-Proc session state.
In case of In-Proc session state, the objects when storing in session, gets stored in the local memory space of W3WP process whereas in case of Out-Proc session sate, the objects gets serialized and stored in database or some other back-end storage. When accessing the session state data in case of Out-Proc, object gets deserialized first and then loaded into process memory. Hence if you notice, the Address object is loaded two times into process’s memory in case of out-proc session state.One instance as a reference of Employee object and another as a stand-alone Address object.
So, Session[“Employee”].Location and Session[“Address”] point to two separate memory locations in case of Out-Proc and same memory location in case of In-Proc session state.
Consider that below line gets executed to change/modify the city of employee to Singapore:
Session[“Employee”].Location.City = “Singapore”;
Now, when reading the city of employee using the below line gives two different results:
Session[“Address”].City // Returns “Singapore” in case of in-proc session state and old/unmodified value in case of out-proc session state
Please be careful in these scenarios, and I personally recommend to test your application by using SQL Session state instead of in-proc session state in local development box before shipping the code to test/staging environment.
It is very easy to configure your local ASP.NET application to use SQL Session state. Follow https://support.microsoft.com/en-sg/kb/317604 to configure SQL Server to store ASP.NET session state.
Happy Programming !!!