ASP.NET overcomes all major limitations of ASP when it comes to managing session states. As you are aware from ASP development, a session state is nothing but a named variable that is cached at the server for the duration of the web user’s session. As the user navigates through the web application, the session state retains its value as long as the session is not expired.
ASP Session state management can be summarized as follows:
The session starts, and the web application assigns a unique key to the user.
This key is stored in an HTTP cookie. Along each subsequent request, the client browser sends the unique key back to the server.
The server looks up the states stored for this particular key and processes the request accordingly.
While this has worked fine for all these years, we’ve found out that there were a number of limitations to live with or work around. The biggest limitation is that the session state is process dependent, which is impossible to implement in a web farm environment without custom session management.
ASP.NET improves upon ASP session-state management by moving to an out-of-process model. By having all web servers in the farm pointing to a common server that hosts the out-of-process state manager, the web client can be redirected around the farm without losing the session states.
By using an out-of-process model, we no longer have the problem of losing session states when the IIS process is cycled. This means that if the web server application crashed for whatever reason and restarted within the session time-out duration, the web clients could still have all their session states intact. Of course, if the out-of-process state manager crashed, that is a whole different issue. This leads to the next improvement of ASP.NET—the ability to persist session state to a database.
The idea of persisting session state to a database is not new. Many of us have implemented this as the workaround for dealing with web farm configuration. However, ASP.NET makes it easier.
Similar to all other configurations in ASP.NET, session management is
done through the use of the
web.config
files. There are two levels of configuration:
machine and
application. Machine-level configuration associates with the
machine.config file stored in
WinNTMicrosoft.NET
Framework<
version>CONFIGmachine.config,while the application-level configuration uses the
web.config file in the application root
directory. The application-level configuration overrides the
machine-level configuration.
The following code is a portion of the
web.config file dealing with session-state
management:
<configuration>
<system.web>
<sessionstate
mode="Inproc"
cookieless="false"
timeout="20" />
</system.web>
</configuration>Table 7-2 lists the properties of the SessionState class.
Table 7-2. Properties of the SessionState class
|
Property |
Description |
|---|---|
|
Off indicates that session state is disabled; Inproc stores session data locally; StateServer stores session state on a remote server; and SqlServer stores it on a SQL Server. | |
|
Specifies whether to rely on the client acceptance of cookie. If this
property is set to | |
|
Specifies session timeout in minutes. This is a sliding window of time: it starts counting down for each request. The default is 20 minutes. | |
|
Specifies the server and port of the remote session-state server (not
a SQL Server). The format is | |
|
Represents a SQL Server connection string, such as
|
When you set the session-state mode to run
on a remote server (mode=StateServer), you must
prepare the remote server to run the state management service
automatically.
ASP.NET SDK includes an NT service call ASP
State
to be used for out-of-process
session-state management. Before setting your
web.config files to use the out-of-process mode,
you will have to start the ASP State service by going to the NT
Services Management Console and start the service. You might want to
change the startup type to
automatic so that this service will start
automatically at subsequent reboots.
To start using this mode, the SQL Server machine has to be prepared.
ASP.NET SDK includes a SQL script to create the ASP State database,
which is where all session states are stored. Find this SQL script
(InstallSqlState.sql ) at
%SystemRoot%Microsoft.NETFramework
BUILDNUMBER. To apply the script to your SQL Server, use
the SQL Server command-line tool osql.exe or SQL
Query Analyzer. We use the latter because it allows us to inspect the
script to get a better understanding of how this mode of session
management is implemented. You will have to stop and restart SQL
Server because the script alters the master to run
the ASPState_Startup helper procedure at SQL
startup time.
In ASP development, it is a usual practice to impose the requirement that the clients’ web browsers be set up to accept cookies so that we can use session state the way it is meant to be used. However, when this requirement is not in place, especially for business-to-consumer (B2C) kinds of applications, the developers have to package the session ID along with the URL as a variable in the query string or as a form field and manage the session states manually.
With ASP.NET, as you can see from the sessionstate
section of the configuration file, all you do is flip the setting of
cookieless to true, and
everything is automatically done for you. Session state can be used
as if nothing has changed.
As we’ve said, ASP.NET introduces an out-of-process model of session-state management, which enables more scalable solutions, but not without a cost. Out-of-process communication performs much worse than in-process communication, not to mention persisting the session states to a database. You should weigh the benefits of each of the different mode of state managements to find the one that is most suitable for your application. Table 7-3 summarizes the different modes and their trade-offs.
Table 7-3. Session-state management communication modes