Session Management Techniques in ASP.Net

Session are the server side method of managing the state of an application i.e. all the web applications' state related info will be stored on server side if we use this technique.

The advantages of using Session State are

• Better security
• Reduced bandwidth

The disadvantages of using Session state are

• More resource consumption of server.
• Extra code/care if a Web form is used

Using Session State

ASP.NET allows us to save values using Session state. It is a global storage mechanism that is accessible from all pages in the Web application. Session state is stored in the Session key/value dictionary. This information will be user specific i.e. for each user separate dictionary will be created and no one can access other session information. below is the Example usage of sessions.

global.asaxvoid Session_Start(object sender, EventArgs e)
{
    // Code that runs when a new session is started    Session["number"] = 0;
}

// Web formsSession["number"] ="123";

To configure the session management we need to specify the settings in the web.config file

<sessionState mode="InProc" 
 stateConnectionString="tcpip=127.0.0.1:42424" 
 sqlConnectionString="Data Source=.\SQLEXPRESS;Trusted_Connection=Yes;" 
 cookieless="false" 
 timeout="100"/>

mode	This specifies the type of session management we want to use. it could be InProc, SQLServer, and StateServer
stateConnectionString	If we use StateServer as session management technique then this specifies the location of the server that is handling the session data.
sqlConnectionString	If we use SQLServer as session management technique then this specifies the database connectionstring that will store the session data.
cookieless	This specifies whether we will be using cookies to identify sessions or we want session info appended in URL. It could be true or false.
timeout	This specifies the time for which the session should be active. after this much time of inactivity the session will expire.

Configuring the Session Modes

Using In-Proc Session Mode

In-Proc Session Mode

If we are using In-Proc session handling then all the session information will be stored in the server memory. This is the default session state in ASP.NET.
This approach works fine as long as we are keeping small session information. Since the memory location was handled by the ASP.NET worker thread only it involves a considerable overhead for the worker thread to manage these. Also, since this is in the memory of server, chances are that large session information would lead to more memory usage and thus lowering the performance.
Let us try to visualize this session management technique.



In-Proc sessions in Web Farm scenario

As we have discussed above the web farm will have a load balancer accepting all the requests. It will then forward the request to any server based on some criteria. Lets try to see a scenario which could create problems for us if we are using In-Proc sessions.

1. The request from Computer1 reaches the load balancer and load balancer forwards it to server1.
2. The In-Proc session led the session data created in the server1's memory.
3. The next request comes from Computer1 and this time load balancer pushes it to Server2.
4. Since the server1 had this user specific data in its memory server2 will not be able to recognize this request leading to failure of our application logic.

So what should we do to tackle this situation. The whole problem was because each server in our web form was keeping the session data in their own memory. If we could somehow move this data from each server memory to a centralized location then we will not face this problem. And that is where the SQLServer and stateServer comes to rescue. using these two approaches we can easily configure a central repository to store session data.

SQLServer Session Mode

If we use the SqlServer mode of session management then the session data will be stored in the SqlServer. The benefit of having this scenario is that the data is stored in a centralized database rather than the server memory. Let us see how this can be configured from web.config

StateServer Session Mode

If we use the StateServer mode of session management then the session data will be stored in a separate computer(server) and the session data will be handled by a windows service. The benefit of having this scenario is that the data is stored in a centralized location i.e. a state server rather than the individual server memory. Let us see how this can be configured from web.config

<sessionState mode="StateServer" 
                stateConnectionString="tcpip=127.0.0.1:42424" 
                sqlConnectionString="Data Source=.\SQLEXPRESS;Trusted_Connection=Yes;" 
                cookieless="false" 
                timeout="100"/>

mode	This specifies the type of session management we want to use. it could be InProc, SQLServer, and StateServer
stateConnectionString	If we use StateServer as session management technique then this specifies the location of the server that is handling the session data.
sqlConnectionString	If we use SQLServer as session management technique then this specifies the database connectionstring that will store the session data.
cookieless	This specifies whether we will be using cookies to identify sessions or we want session info appended in URL. It could be true or false.
timeout	This specifies the time for which the session should be active. after this much time of inactivity the session will expire.

mode	This specifies the type of session management we want to use. it could be InProc, SQLServer, and StateServer
stateConnectionString	If we use StateServer as session management technique then this specifies the location of the server that is handling the session data.
sqlConnectionString	If we use SQLServer as session management technique then this specifies the database connectionstring that will store the session data.
cookieless	This specifies whether we will be using cookies to identify sessions or we want session info appended in URL. It could be true or false.
timeout	This specifies the time for which the session should be active. after this much time of inactivity the session will expire.