Using the ASP.NET State Service for State Management in ASP.NET Among Several Server

One of the problems about earlier was session state management across a Web farm. When users come into a Web site with several servers that can serve a particular user at any time, the session state does not automatically carry over from machine to machine. Another problem with session state is that it typically runs in the same process space as the IIS service. As a result, if our IIS service goes down, we also lose all session states.

If we wish to solve both of these problems, we need to move the session state management to an out-of-process component that is separate from the IIS service. When the .NET Framework is installed, a new service called ASP.NET State is installed on our server. This service manages the Session object in a separate process. This separate process can be located on the same machine as IIS, or on a separate machine.

If we choose to use a separate server to be the state management machine, all the servers in our Web farm use this machine to store and retrieve state for a user. No matter which machine serves the user, the state is maintained on a separate machine, one from which each of these Web servers can retrieve data.

We are probably thinking that this is going to be very difficult to set up and maintain. Nothing could be further from the truth! In fact, all it takes is to change one setting in each Web server’s Web.Config file.

Follow the steps below to enable an out-of-process session state manager.

• Using the Services applet, start the ASP.NET State Service.
• Open application’s Web.Config file in the Visual Studio.NET editor.
• Locate the <sessionState> XML element.
• Change the Mode attribute from InProc to StateServer.
• Make sure the Cookieless attribute is set to true.

<sessionState

mode=”StateServer”

stateConnectionString=”tcpip=127.0.0.1:42424″

sqlConnectionString=”data source=127.0.0.1;user

id=sa;password=”

cookieless=”true”

timeout=”20″

/>

After setting this attribute, we can test our changes:

• Run some code that creates a session variable.
• Stop and re-start the IIS Admin and Web Publishing Services.
• Go back to a page that retrieves the session variable that we previously set: we’ll find that the saved variable still exists.

If we will be using a separate machine for state management, make sure that the ASP.NET State service is running on this other machine. Next, set the stateConnectionString attribute in the <sessionstate> XML element to the name or IP address of the machine that will manage the state.

TIP:  By default, the stateConnectionString attribute is set to 127.0.0.1, which corresponds to the current machine. If we want to manage state on a separate machine, we’ll need to modify this value.

Issues With the ASP.NET State Service

There are some issues with using this ASP.NET State service:

• Performance: The performance of retrieving state from an out-of-process service will be slower than from an in-process service. If we are retrieving data across the network to a state server, we also have the network traffic to contend with. This can slow our retrieval of state significantly.
• Redundancy: If we use another machine to manage state, we will need to set up some redundancy for this machine in case it crashes. Of course this redundancy will not help us if the original machine dies, because all of the session data is stored in memory.