One of the problems you learned about earlier involved session state management across a Web farm. In particular, when users come to a Web site that uses 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 your IIS service goes down, you also lose all session states.
Using a Separate State Server Machine
If you wish to solve both of these problems, you 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 your 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.
The ASP.NET service is not supported on Windows 98/Me.
If you choose to use a separate server to be the state management machine, all the servers in your Web farm use this machine to store and retrieve the state information for a user. No matter which machine serves the user, the state is maintained on a separate machine, one from which all the Web servers can retrieve data.
You're probably thinking that this is all very difficult to set up and maintain. Nothing could be further from the truth! In fact, all you have to do is change one setting in each Web server's Web.Config file.
Follow these steps to enable an out-of-process session state manager:
Using the Services applet, start the ASP.NET State Service.
Open your 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, as shown here:
<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, you can test your changes.
Run some code that creates a session variable.
Stop and restart the IIS Admin and Web Publishing Services.
Go back to a page that retrieves the session variable that you previously set. You'll find that the saved variable still exists.
If you 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.
By default, the stateConnectionString attribute is set to 127.0.0.1, which corresponds to the current machine. If you want to manage state on a separate machine, you'll need to modify this value.
Issues with the ASP.NET State Service
Here are some issues with using this ASP.NET State Service:
Performance. The performance of retrieving state information from an out-of-process service will be slower than from an in-process service. If you are retrieving data across the network to a state server, you also have the network traffic to contend with. This can slow your retrieval of state information significantly.
Redundancy. If you use another machine to manage state, you will need to set up some redundancy for this machine in case it crashes. Of course, this redundancy will not help you if the original machine dies, because all the session data is stored in memory.