Session State Management

  • Article

 

 

  1. InProc
    1. Sessions are stored in worker process memory.
    2. Performance wise it is fastest but performance could be decreased if large and persistent objects are stored for a long time.
    3. Session data will be lost if worker process or the app domain recycles. Following could the reasons if session data is getting lost in InProc mode.

                                             i. Global.asax, web.config or machine.config is changed.

                                             ii. Bin directory of the application is modified.

                                             iii. When virus scanning software touches some .config file or probes into bin directory.

                                             iv. Various values of memoryLimit attribute inside <processModel> section.

    1. This mode will not work in web garden mode or in the NLB environment.
    2. Session_End event is only fired when InProc mode is used.
  1. State Server
    1. Sessions are stored in memory outside of aspnet worker process.
    2. State server where sessions are stored can be run on another server.
    3. Communication between aspnet worker process and the sate server is done in TCP.
    4. It is slower then InProc mode since communication overhead is present between worker process and state server.
    5. Serialization and De- Serialization of data also takes time and can affect performance.
    6. Basic/Predefined data types are serialized/de-serialized by asp.net but other data types used binary formatter for doing this and it hits performance.
    7. Can be used if web gardens are configured or if the application is running on NLB environment.
    8. We have to make sure that the objects are serializable.
    9. If Web farm is there make sure <machineKey> on each web server is same. Please follow the link to generate the machine key from https://support.microsoft.com/?id=313091 . (NOTE: - Machine key is also needed when we use: -

                                          i. Forms Authentication in web farm scenario.

                                          ii. When we want view state to be available across the web farm.

    1. If session state is still not persisting in the network load balanced scenario make sure that Application path for the website on each server is same. Instance ID’s of application on each server should be the same.
  1. SQL Server
    1. Sessions are stored in SQL server.
    2. Sessions inside SQL server can be persistent or non-persistent. It depends on the SQL script that we ran from C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322. If worker process recycles in both of the cases session data will be restored. No matter what type of SQL Script we ran. But if we want to persist session data even after the reboot of SQL servers then we have to run InstallPersistSqlState.sql rather than InstallSqlState.sql.
    3. It is even slower then State Server mode. So while designing the application we need to take care of the performance.
    4. All the web farm and NLB settings that apply on State Server are similar to SQL Server.
    5. In framework 1.0 if we try to store objects in session which are not serialized then we may encounter hangs in the application. However this problem is fixed in V 1.1.

Some Troubleshooting tips on session problems

 

  • Sessions may not work for some clients (browsers) if cookies are turned off. Here is the sample java script code in order check whether the cookies are enabled.

         <html>

<head>

<script language="javascript">

function CheckCookies()

{

            //Create a Test cookie.

            var testcookie = 'jscookietest=valid';

            // Add this cookie in the cookie in the cookies collection of the document object.

            document.cookie = testcookie;

            if (document.cookie.indexOf(testcookie) == -1)

            {

                        // If cookies is not created it means that cookies are not supported. So just redirect user to HTML/ASPX Page

                        // stating that cookies are enabled.

                        window.location.href = "Any HTML Page";

                        return false;

            }

            // It means cookies are enabled.

            return true;

}

</script>

</head>

<body onLoad="javascript: return CheckCookies();">

Cookies are enabled.

</html>

  • Sessions may not work if SessionStateModule is not registered inside machine.config file. Normally we can find its entry in machine.config as

<httpModule>

       <add name="Session"

        type="System.Web.SessionState.SessionStateModule"/>

………………

</httpModule>

 

Also note that sometime share point removes this module inside its web.config and as a result session state is not available.

 

NOTE: - SessinStateModule helps in managing session states. Its purpose is to generate or obtain session ID and for storing and retrieving session data for every request.

  • If sessions are not working for a specific aspx page we can check whether EnableSessionState attribute is set to true or false.

  • Session_End will not fire if the browser is closed because HTTP is a stateless protocol. It will only fire if: -

    • Timeout value is reached.

    • If Session.Abandon() is explicitly called.

    • If any error happens in Session_End it will not report any errors.

    • For Session_End to be fired session state must exist i.e. there should be some data in the session variables.

  • Session ID will remain same as long as the browser instance is not closed even if session is timed out or abandoned. However the session data will loose after session time out or if session is abandoned.

  • Session ID will change on every request only when nothing is stored in session state.

  • If you are calling Session.Abandon() then Session_End event will be fired and after that Session_Start will fire for the subsequent request.

  • Session.Clear()doesn’tinvokes Session_End event.

  • We can’t share sessions between two web applications because one application cannot access the application domain of another application.

  • ASP.NET intrinsic Objects like Request, Response, and Context are not available inside Session_End event.

  • If you have created your own Http Handler do not forget to implement by IRequireSessionState interface. This is a marker interface which means that it has no method. SessionStateModule will take care of maintaining the session states which is declared in machine.config under <httpModules> section.

  • Problems in cookie less sessions: -

    • First of all when session state is set to cookie less the session ID will accompany the URL with query string.
    • If session ID is present in the URL then it leads to Session Fixation attacks. More details on session fixation could be find at https://www.acrossecurity.com/papers/session_fixation.pdf
    • SessionStateModule doesn’t guarantee each and every time when it creates Session ID to be unique. So suppose user “A” hits the URL first time and he is assigned the session Id and then he saves the URL. User “B” hits the website and he also gets Session ID. Now if user “A” after some time opens up the saved URL there might be chances that he starts seeing the session data for user “B”. This can be prevented by writing a simple Http Handler.

That's all for now on Session Mgmt. I will keep adding more and more findings as an when i encounter them in ASP.NET 1.0/1.1 as well as 2.0 !!!