You need to configure your application to maintain session state across multiple web serversfor example, in a load-balanced web farm or web garden.
When the data stored in session is easy to re-create or is not critical, configure your application to use the ASP.NET State Service using the following four steps:
When you must not lose any session information if server problems arise, use SQL Server to store all session information, as follows:
ASP.NET provides in-process session management much like classic ASP. However, scaling to multiple servers in classic ASP has always been difficult because session information is not shared between ASP servers. There are ways to solve the problem in classic ASP but all are hard and code changes are generally required when you move to a multiple-server configuration.
ASP.NET provides two methods for managing session state when you decide to deploy a web application on multiple servers: the ASP.NET State Service and support for session state storage in SQL Server.
The ASP.NET State Service is an out-of-process, memory-based session management service that is intended to be used when the data stored in session is easy to recreate or is not critical. The SQL Server-based session management uses SQL Server to store all session information and is intended to be used when you must not lose any session information if server problems arise. As you might expect, the performance of SQL Server in maintaining session state management is worse than the ASP.NET State Service because of the overhead involved in querying and writing session information in a database. The ASP.NET State Service will have a poorer performance as the default in-process storage of an ASP.NET application because of the out-of-process communications and network hops involved in communicating with other servers across a network.
The out-of-process State Service and SQL Server session management techniques are compatible with each other and require no changes to your code when you move from one technique to another, which you might do, for example, if you are losing critical session information.
If you choose to make use of the ASP.NET State Service, install and run it on a server separate from the web servers in the web farm. This allows any one of the web servers to be taken down for maintenance or replacement without interrupting access to your application. If the ASP.NET State Service is running on a server running an instance of the application, when that server requires maintenance, your entire application will be unavailable while the server is down.
You start the ASP.NET State Service the same way you start any other Windows service. Invoke the Services console by clicking on Start Control Panel and selecting Administrative Tools and then Services. In the Services console window, select the ASP.NET State Service, as shown in Figure 12-1.
Figure 12-1. Starting the ASP.NET State Service
Right-click the ASP.NET State Service and select Properties to open the ASP.NET State Service Properties dialog box. From the Startup type drop-down menu, select Automatic to start the service automatically any time the server is restarted, and then click the Start button to start the service, as shown in Figure 12-2.
Figure 12-2. Setting the ASP.NET State Service's Startup type property to Automatic
To use the ASP.NET State Service, you must make two changes to the application web.config file on its current web server. First, add a <sessionState> element to the web.config file in the root directory of your application (unless the element is present). Next, set (or change) the mode attribute to "StateServer" and modify the stateConnectionString attribute to include the IP address of the server running the ASP.NET State Service. We'll refer to that machine as the state server from here on. Do not change the port number because this is the port the State Service is listening on. If you must change the port number, you will need to make changes to the registry settings for the State Service because the port number cannot be changed through the Services console. Here's some sample code that demonstrates the changes we've described:
<?xml version="1.0"?> <configuration> <system.web> … <sessionState mode="StateServer" stateConnectionString="tcpip=10.0.1.11:42424" cookieless="false" timeout="20" /> … </system.web> </configuration>
In addition to modifying <sessionState> settings in web.config, you will need to alter the keys used for encryption and generation of unique values. Session management uses these keys to generate session IDs and hash values used in the session collection, so all servers must be configured to use the same values. If the values differ from server to server, the session information will not be understood by all of the servers hosting the application. You control encryption through the <machineKey> element, which you will need to add to the web.config file. By default, the keys are set to generate values automatically that will result in a different key being used on each server. These values should be set to 40128 hexadecimal characters as a function of the encryption type and level. Note that [YourHexValue] must be replaced with the hexadecimal value you want to use for your application:
<?xml version="1.0"?> <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <system.web> … <machineKey validationKey="[YourHexValue]" decryptionKey="[YourHexValue]" validation="SHA1"/> … </system.web> </configuration>
After you've tested your application with the ASP.NET state server enabled, you're ready to deploy it to the other servers.
An alternate approach to using the ASP.NET state server is to use SQL Server to store and persist the session information. ASP.NET again makes this a simple configuration change with no code changes required.
The first step to using SQL Server for session management is to install the special tables and stored procedures that ASP.NET requires in the instance of SQL Server that you will use for this purpose. You create this support by running the InstallSqlState.sql script provided with the .NET Framework.
To run the script, open a command prompt and navigate to the folder \WINNT\Microsoft.NET\Framework\<version>, where <version> is the version of the .NET Framework installed on your SQL Server machine. At the command prompt, type the following, and all of the necessary tables, stored procedures, and the like will be installed. You will need to substitute for password the appropriate password for the sa account:
OSQL -S localhost -U sa -P password < InstallSqlState.sql
For a production application, set up a database user with read/write access to the tempDB database. You will use this database user in the configuration described next.
The only other change required to use SQL Server for state management is to modify the web.config file, as shown here, setting the mode to SQLServer, setting the IP address to the address of your SQL Server machine, and replacing user and pwd with the settings for the database user with read/write access to the tempDB database:
<sessionState mode="SQLServer" sqlConnectionString="data source=10.0.1.12;user id=user;password=pwd" cookieless="false" timeout="20" />
From now on, when your application runs, it will use SQL Server for storing all of its session information. You can see the results of this by looking at the ASPStateTempApplications and ASPStateTempSessions tables in the tempDB database. You should find entries there for your applications and sessions, respectively. Because the data is stored in binary format, you will not be able to view it.
Two other sessionState element attributes are frequently used in conjunction with the other modifications that we've discussed: cookieless and timeout.
The article by Rob Howard titled "ASP.NET Session State (Nothin' but ASP.NET)" in the MSDN library (search "ASP.NET Session State")