Configuring Session State
You can configure session state through the <sessionState> element in the web.config file for your
application. Here’s a snapshot of all the available settings you can use:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<!-- Other settings omitted. -->
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424" stateNetworkTimeout="10"
sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI"
sqlCommandTimeout="30" allowCustomSqlDatabase="false"
useHostingIdentity="true"
cookieless="UseCookies" cookieName="ASP.NET_SessionId"
regenerateExpiredSessionId="false"
timeout="20"
customProvider=""
/>
</system.web>
</configuration>
The session attributes are described in the following sections.
Mode
The mode session state settings allow you to configure what session state provider is used to store
session state information between requests. The following sections explain your options.
Off
This setting disables session state management for every page in the application. This can provide a
slight performance improvement for websites that are not using session state.
InProc
InProc is similar to how session state was stored in classic ASP. It instructs ASP.NET to store information
in the current application domain. This provides the best performance but the least durability.
If you restart your server, the state information will be lost.
InProc is the default option, and it makes sense for most small websites. In a web farm scenario,
though, it won’t work at all. To allow session state to be shared between servers, you must use
the out-of-process or SQL Server state service. Another reason you might want to avoid InProc
mode is because it makes for more fragile sessions. In ASP.NET, application domains are recycled in
response to a variety of actions, including configuration changes, updated pages, and when certain
thresholds are met (regardless of whether an error has occurred). If you find that your application
domain is being restarted frequently and contributing to prematurely lost sessions, you can try to
counter the effect by changing some of the process model settings (see Chapter 18), or you can
change to one of the more robust session state providers.
Before you use either the out-of-process or the SQL Server state service, keep in mind that
more considerations will apply:
• When using the StateServer or SqlServer mode, the objects you store in session state must be
serializable. Otherwise, ASP.NET will not be able to transmit the object to the state service or
store it in the database.
• If you’re hosting ASP.NET on a web farm, you’ll also need to take some extra configuration
steps to make sure all the web servers are in sync. Otherwise, one might encode information
in session state differently than another, which will cause a problem if the user is routed
from one server to another during a session. The solution is to modify the <machineKey>
section of the machine.config file so it’s consistent across all servers. For more information,
refer to Chapter 5.
• If you aren’t using the in-process state provider, the SessionStateModule.End event won’t
be fired, and any event handlers for this event in the global.asax file or an HTTP module
will be ignored.
StateServer
With this setting, ASP.NET will use a separate Windows service for state management. Even if you
run this service on the same web server, it will be loaded outside the main ASP.NET process, which
gives it a basic level of protection if the ASP.NET process needs to be restarted. The cost is the
increased time delay imposed when state information is transferred between two processes. If you
frequently access and change state information, this can make for a fairly unwelcome slowdown.
When using the StateServer setting, you need to specify a value for the stateConnectionString
setting. This string identifies the TCP/IP address of the computer that is running the StateServer
service and its port number (which is defined by ASP.NET and doesn’t usually need to be changed).
This allows you to host the StateServer on another computer. If you don’t change this setting, the
local server will be used (set as address 127.0.0.1).
Of course, before your application can use the service, you need to start it. The easiest way to
do this is to use the Microsoft Management Console. Select Start ➤Programs ➤Administrative
Tools ➤Computer Management (you can also access the Administrative Tools group through the
Control Panel). Then select the Services and Applications ➤Services node. Find the service called
ASP.NET State in the list
SqlServer
This setting instructs ASP.NET to use an SQL Server database to store session information, as identified
by the sqlConnectionString attribute. This is the most resilient state store but also the slowest
by far. To use this method of state management, you’ll need to have a server with SQL Server
installed.
When setting the sqlConnectionString, you follow the same sort of pattern you use with
ADO.NET data access (which is described in Part 2). Generally, you’ll need to specify a data source
(the server address) and a user ID and password, unless you’re using SQL integrated security.
In addition, you need to install the special stored procedures and temporary session
databases. These stored procedures take care of storing and retrieving the session information.
ASP.NET includes a Transact-SQL script for this purpose called InstallSqlState.sql. It’s found in the
c:\[WinDir]\Microsoft.NET\Framework\[Version] directory. You can run this script using an SQL
Server utility such as OSQL.exe or Query Analyzer. It needs to be performed only once. If you decide
to change your state service, you can use UninstallSqlState.sql to remove the state tables.
The session state timeout still applies for SQL Server state management. That’s because the
InstallSqlState.sql script also creates a new SQL Server job named ASPState_Job_DeleteExpired
Sessions. As long as the SQLServerAgent service is running, this job will be executed every minute.
Additionally, the state tables will be removed every time you restart SQL Server, no matter what
the session timeout. That’s because when you use InstallSqlState, the state tables are created in the
tempdb database, which is a temporary storage area. If this isn’t the behavior you want, you can use
the InstallPersistSqlState.sql and UninstallPersistSqlState.sql scripts instead of InstallSqlState.sql
and UninstallSqlState.sql. In this case, the state tables are created in the ASPState database and are
permanent.
Ordinarily, the state database is always named ASPState. As a result, the connection string in
the web.config file doesn’t explicitly indicate the database name. Instead, it simply reflects the location
of the server and the type of authentication that will be used:
<sessionState sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI"
... />
If you want to use a different database (with the same structure), simply set allowCustom-
SqlDatabase to true and make sure the connection string includes the Initial Catalog setting, which
indicates the name of the database you want to use:
<sessionState allowCustomSqlDatabase="false" sqlConnectionString=
"data source=127.0.0.1;Integrated Security=SSPI;Initial Catalog=CustDatabase"
... />
When using the SqlServer mode, you can also set an optional sqlCommandTimeout attribute
that specifies the maximum number of seconds to wait for the database to respond before canceling
the request. The default is 30 seconds.
