ASP.NET gives you several choices for managing
session state. You can turn it off completely, you can run session state
in the ASP.NET worker process, you can run it on a separate state
server, or you can run it from a SQL Server database. Here's a rundown
of the options available:
Don't use it at all. By disabling
session state, your application performance will increase because the
page doesn't need to load the session when starting, and neither 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 between
page invocations.
Store session state "in proc." 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 Internet Information Services (IIS)
or somehow knock the server down, all session state is lost. In some
cases, this might not be a big deal. However, if the shopping cart
contains sizable orders, losing that might be a big deal. In addition,
the in-process session manager is confined to a single computer, meaning
you can't use it in a Web farm. (A Web farm is a group of servers tied together to serve Web pages as a single application.)
Store session state in a state server.
This option tells the ASP.NET runtime to direct all session management
activities to a separate Windows Service process running on a particular
computer. With this option, you have the advantage of running your
server in a Web farm. The ASP.NET session state facilities support Web
farms explicitly. To run in a Web farm, you direct all your applications
to go to the same place to retrieve session information. The downside
of 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. To reduce the overall
size of the stored information, when storing
session data in the state server, with ASP.NET 4 you now have the
option of using compression to reduce the amount of data being
transferred. Just include the compressionEnabled=true setting in the sessionState section of web.config.
Store session state in a database.
Configuring your application to use a SQL Server database for state
management causes ASP.NET to store session information in a SQL Server
database somewhere on your network. Use this option when you want to run
your server from in a Web farm when you want session state to be
durable and safe. As with the state server approach, when storing
session data in the SQL Server database, you have the option of using
compression to reduce the amount of data being transferred. Again just
include the compressionEnabled=true setting in the sessionState section of web.config.
When you configure
ASP.NET session state during development, you can edit the configuration
file directly. After your site is deployed, you might prefer to
configure session state through the session state configuration page in IIS:
1. Turning Off Session State
The ASP.NET session
state configuration tool available through IIS touches your Web site's
web.config file and inserts the right configuration strings to enforce
the settings you choose. To turn off session state completely, select
Off from the session state mode control.
2. Storing Session State InProc
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 the session state
information is available to your application only on the particular
server on which the session information was originally stored. (That is,
the session information is not available to other servers that might be
working together on a Web farm.)
3. Storing Session State in a State Server
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 Connection String text box and the network Timeout text box become available. Insert the protocol, IP address, and port for the state server in the Connection String text box. For example, the string
tcpip=loopback:42424
will store the session state on the local computer over port
42424. If you want to store the session state on a computer other than
your local server, simply provide its IP address in place of loopback. Before session state is stored on a server, you need to make sure the ASP.NET state
service is running on that computer. You can get to it using the
Services icon in Control Panel and Administration Tools, as shown in the
following graphic, which shows the Services control panel:
4. Storing Session State in a Database
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 are asked to enter
the connection string to the SQL Server state database. Here's the
string provided by default:
data source=localhost;Integrated Security=SSPI
You can configure ASP.NET so
that it references a database on another server. Of course, you need to
have SQL Server installed on the target server to make this work. In
addition, you can find some SQL scripts to create the state databases in
your .NET system directory
(C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 on my computer at the
time of this writing). The aspnet_regsql.exe tool sets up the databases
for you.
