ASP.NET gives you several choices for managing session state. You can turn it off completely, you may run session state in the ASP.NET worker process, you may run it on a separate state server, or you may run it from a SQL Server database. Here's a rundown of the options available:
By disabling session state, your application performance will increase because the page doesn't need to load the session when starting, nor does it need to store session state when it's going away. On the other hand, you won't be able to associate any data with a particular user.
This is how session state is handled by default. In this case, the session dictionaries (the Session objects) are managed in the same process as the page and handler code. The advantage of using session state in process is that it's very fast and convenient. However, it's not durable. For example, if you restart IIS or somehow knock the server down, all session state is lost. In some cases, this may not be a big deal. However, if your shopping cart represents a shopping cart containing sizeable orders, losing that might be a big deal. In addition, the in process Session manager is confined to a single machine, meaning you can't use it in a Web form.
This option tells the ASP.NET runtime to direct all session management activities to a separate daemon process running on a particular machine. This option gives you the advantage of running your server in a Web farm. A Web farm is a group of servers tied together to serve Web pages. The ASP.NET Session State facilities support Web farms explicitly. To run in a Web form, you would direct all your applications to go to the same place to retrieve session information. The downside to this approach is that it does impede performance somewhat—applications need to make a network round-trip to the state server when loading or saving session information.
Configuring your application to use a SQL Server database for state management causes ASP.NET to store session information within a SQL Server database somewhere on your network. Use this option when you want to run your server from within a Web form when you want session state to be durable and safe.
There are two ways to configure ASP.NET: the hard way and the easy way. As with most other configuration settings, the ASP.NET session state configuration ultimately happens within the Web.Config file. As always, you may configure Web.Config the hard way by using the typing Wizard (that is, typing the settings in by hand). Alternatively, you may use the ASP.NET Configuration Settings dialog box from IIS.
The ASP.NET session state configuration tool available through IIS will touch your Web site's Web.Config file and insert the right configuration strings to enforce the settings you choose. To turn off session state completely, select Off from the session state mode control.
To store session state in the ASP.NET worker process, select InProc from the session state mode control. Your application will retrieve and store session information very quickly, but it will be available only to your application (and not on a Web form).
To have ASP.NET store session state on another server on your network, select StateServer from the SessionState mode control. When you select this item, the dialog box will enable the Connection String text box and the network timeout text box. Insert the protocol, IP address, and port for the state server in the Connection String text box. For example, the string:
will store the session state on the local machine over port 42424. If you want to store the session state on a machine other than your local server, change the IP address. Before session state is stored on a machine, you need to make sure the ASP.NET state server is running on that machine. You may get to it via the Services panel under the control panel.
The final option for storing session state is to use a SQL Server database. Select SQLServer from the ASP.NET session state mode combo box. You'll be asked to enter the connection string to the SQL Server state database. Here's the string they provide by default:
data source=127.0.0.1;Integrated Security=SSPI
You may point ASP.NET so it references a database on another machine. Of course, you need to have SQL Server installed on the target machine to make this work. In addition, you'll find some SQL scripts to create the state databases in your .NET system directory (C:\WINDOWS\[[<img src="images/shy.gif"/>]]Microsoft.NET\Framework\v2.0.50215 on this machine at the time of this writing). The Aspnet_regsql.exe tool will set up the databases for you.