Configuring Session State Storage

ASP.NET provides several new possibilities for storing session state. Each is designed to overcome one or more of the limitations of session state in classic ASP. The available settings include the following:

In-process (InProc) This is the default setting. Its behavior is essentially the same as in classic ASP.
Out-of-process (StateServer) This setting specifies that session state will be stored by a server running the ASP.NET state service. The state server to connect to is specified by an attribute, as described in the section “Storing Session State Out-of-Process” later in this chapter.
SQL Server (SQLServer) This setting specifies that session state will be stored in a Microsoft SQL Server database. The SQL Server to connect to is specified by an attribute, as described in the section “Storing Session State in SQL Server” later in this chapter.
Cookieless Sessions This setting allows you to maintain session state even for users whose browsers cannot handle cookies.

The following sections describe how to configure each of these settings.

Storing Session State In-Process

By default, Web applications, whether created in Visual Studio .NET or created manually, will store session state in-process. As noted, this setting has several inherent limitations, including lack of scalability and durability. For applications requiring neither scalability beyond a single server nor durability of session state across server restarts or crashes, however, this setting might work just fine. And it’s the simplest to deal with because it doesn’t require any changes to the application configuration file.

Storing Session State Out-of-Process

The first solution to the problems of scalability and durability for session state is to store session state out-of-process in a separate dedicated ASP.NET state process running as a service on a specified server. One advantage of this method is that the ASP.NET State Service can service requests from multiple servers, making it possible to scale session state across a Web farm. Another advantage is that the ASP.NET State Service runs in a separate process (or even on a separate machine), so state information can survive restarts or crashes of a specific Web application process. Note that session state information stored by the ASP.NET State Service does not survive a restart or crash of the machine on which the state service is running.

Store session state out-of-process

Open the Web.config configuration file for your application by double-clicking it in the Solution Explorer window, and then locate the sessionState configuration section.
Change the mode attribute from InProc to StateServer.
Modify the stateConnectionString attribute so that it reflects the server name (or IP address) of the state server and the port that the ASP.NET State Service is monitoring. (By default, this is 42424. The value is stored in the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\ aspnet_state\Parameters under Port.) Save Web.config.
The complete sessionState configuration section that uses the ASP.NET State Service on the local machine would look like the following code. (Note that the sqlConnectionString attribute, which is not used in this example, and the cookieless and timeout attributes have been omitted. The full list of attributes is available in Appendix B.)
```
<sessionState     mode="stateserver    stateConnectionString="tcpip=127.0.0.1:42424"/>
```
Start the Services Microsoft Management Console (MMC) snap-in by clicking Start, then selecting All Programs, then selecting Administrative Tools, and then selecting Services. Note that you must be logged in as an administrator to see the Administrative Tools folder (if you are not logged in as an administrator, you can still access this folder from the Control Panel, but you will need to use the Run As feature to run the Services MMC snap-in using an administrative account).
Start the ASP.NET State Service on the desired server from the Services MMC snap-in. The Windows XP Professional Services snap-in is shown in the following illustration.

ASP.NET will automatically connect to the specified state server to store session state for your application. If the state service on the specified server is not running or the server is not accessible, you will receive an error message.

Keep in mind that although storing session state in a dedicated server process can improve the overall scalability of your application, moving session state out-of-process has inherent performance implications. Retrieving state information from a different process (and especially from a different machine) is significantly more costly than retrieving it from within the same process. You should test the impact on the type and amount of session data you plan to store before implementing this type of session state storage in a production application.

Storing Session State in SQL Server

The second solution to the problems of scalability and durability for session state is to store it out-of-process in a SQL Server database. One advantage of this method is that the specified SQL Server can service requests from multiple servers, making it possible to scale session state across a Web farm. Also, the session state information is stored in a SQL Server database, so state information can survive restarts or crashes of any Web application process, any Web server, or even the SQL Server itself.

Store session state in SQL Server

Set up the SQL Server session state database by running the InstallSqlState.sql SQL script file (located in the Microsoft .NET Framework install directory, by default %windir%\Microsoft.NET\Framework\%version%) against the SQL Server you plan to use. (For more information on running SQL script files, check with your database administrator or the SQL Server Books Online.)
Open the Web.config configuration file for your application and locate the sessionState configuration section.
Change the mode attribute from InProc to SQLServer.
Modify the sqlConnectionString attribute so that it reflects the IP address of the desired SQL Server and the user ID and password used to access the SQL Server, and then save Web.config.
The complete sessionState configuration section that uses a SQL Server on the local machine would look like the following. (Note that the stateConnectionString attribute and the cookieless and timeout attributes have been omitted.)
```
<sessionState    mode="SQLServer   sqlConnectionString="data source=127.0.0.1   user id=sa;password="/>
```

Important

There are security implications to placing the SQL Server user ID and password in the connection string in Web.config. A better practice, where possible, is to use a trusted connection to SQL Server. Chapter 9 describes the steps necessary to use a trusted connection with SQL Server, as well as other connection techniques. Chapter 6 further explores the topic of security in ASP.NET, including good practices for storing connection string information.

Using Cookieless Sessions

One ongoing challenge for Web developers using classic ASP is how to handle session state for users whose browsers can’t or won’t accept cookies. Classic ASP provided no intrinsic solution for this situation. In ASP.NET, it’s relatively simple.

Configure cookieless sessions

Open the Web.config configuration file for your application and locate the sessionState configuration section.
Change the cookieless attribute from false to true.
The complete sessionState configuration section would look like the following. (Note that the stateConnectionString, sqlConnectionString, and timeout attributes have been omitted.)
```
<sessionStat    cookieless="true"/>
```
When the cookieless attribute is set to true, ASP.NET will automatically embed the SessionID value in the URL for all requests. For best results, always use relative URLs for internal links within your application. Relative URLs contain only the path and file information for the requested resource, not the protocol and domain, which are assumed to be the same as the current page.

Formatting URLs for Cookieless Sessions

ASP.NET provides automatic embedding of session IDs in the relative URLs within your application, but not for absolute URLs, nor for URLs from applications outside yours. If a request for a page within an application set up for cookieless sessions is received that doesn’t contain an embedded session ID, ASP.NET will create a new session ID and embed it in the URL for that request.

To prevent this problem, you can manually format URLs by calling the ApplyAppPathModifier method of the intrinsic Response object, and passing it a virtual path. The method will return an absolute URL containing the embedded SessionID for use with cookieless sessions. An absolute URL includes the protocol, domain, path, and file name necessary to request a given resource. The syntax for this method is as follows:

string myAbsoluteURL myAbsoluteURL = Response.ApplyAppPathModifier("foo.aspx");