Introduction
One of the core aspects that classic ASP developers (including me) always deal with when building applications is handling state information. This task is made more difficult in Web applications because HTTP is, by its very nature, a stateless protocol that doesn�t remember anything about a user between requests.
The problem with user sessions in ASP
The stateless nature of HTTP makes the inclusion of a mechanism to save application state between user requests a must�the server must be able to identify the same user across multiple requests. Classic ASP included a Session object that accomplished this, but unfortunately, that implementation has two main weaknesses.
First, the 120-bit session ID used to identify the session is always stored as a cookie on the browser. So, if the security policy of a user's employer disallows cookies, the Session object cannot be populated.
Second, the data associated with the session and accessed through the session ID is stored on the Web server that processed the initial request and started the session. As a result, the session data can�t be shared in a web farm scenario where multiple web servers are processing requests from multiple clients. Although programmatic techniques, and system software such as the Windows 2000 clustering services and Application Center 2000, can be configured to force a client to access the same web server for each request (referred to as �sticky IP�), the overhead and possible imbalance that this situation creates reduces scalability.
ASP.NET�s improved model offers more alternatives.
The ASP.NET session implementation addresses both of these weaknesses by allowing for "cookieless" sessions and off-server storage of session data. The ASP.NET session state module is configured declaratively in the Web.config file like so:
<sessionState mode="InProc" cookieless="false" timeout="20" />
In this case, the mode attribute is set to InProc (the default) to indicate that the session state is stored in memory by ASP.NET and that cookies will not be used to pass the session ID. Instead, the session ID is inserted into the query string for a page�s URL. For example, using InProc mode, after a session is established, a call to a hypothetical ASP.NET page would look something like the following:
http://my.website.com/(55mfgh55vgblurtywsityvjq)/education.aspx
The long alphanumeric string in parentheses is the session ID. The ASP.NET engine extracts the session ID from the query string and can then associate the user request with the appropriate session. In this way, cookies are not required, nor are hidden form fields. So, pages without forms can still participate in the session.
As with ASP before it, session state management in ASP.NET requires overhead. So, if a particular page will not be accessing the Session object, developers can set the EnableSessionState attribute of the Page directive for that page to False. If a particular page will be accessing the Session object and not altering the value of the session, then set the EnableSessionState attribute of the Page directive for that page to Readonly. Session state can be disabled for an entire site by setting the mode attribute of the sessionState element to Off in the Web.config.
ASP.NET offers three session management solutions. They are:
- InProcess,
- StateServer (outProcess),
- SQLServer (database based)
I am going to explain in detail about the new session management options with ASP.NET, especially SQLSEVER and STATESERVER.
InProc
This is same as the conventional ASP session management. Session is stored in memory on the web server.
StateServer session management
A second option, accomplished by setting the mode attribute to StateServer, is storing session data in a separate in-memory cache controlled by a Windows service running on a separate machine. The state service, called the ASP.NET State Service (aspnet_state.exe), is configured by the stateConnectionString attribute in the Web.config file. It specifies the service�s server and the port it monitors:
<sessionState mode="StateServer"
stateConnectionString="tcpip=myserver:42424" cookieless="false" timeout="20" />
In this case, the state service is running on a machine called myserver on port 42424, which is the default. At the server, the port can be changed by editing the Port value in the HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state registry key. Obviously, using the state service has the advantages of process isolation and sharability across a web farm. However, if the state service is stopped, all session data is lost. In other words, the state service does not persistently store the data as SQL Server does; it simply holds it in memory.
Session management with SQL Server
ASP.NET also allows you to store session data on a database server by changing the mode attribute to SqlServer. In this case, ASP.NET attempts to store session data on the SQL Server specified by a sqlConnectionString attribute that would contain the data source and security credentials necessary to log on to the server. To configure the SQL Server with the appropriate database objects, an administrator would also need to create the ASPState database by running the InstallState.sql script found in the WinDir\Microsoft.Net\Framework\Version folder (where WinDir is the name of your server�s Windows folder and Version is the installation folder for the appropriate version of the .NET Framework you�re using).
<sessionState mode="SqlServer"
sqlConnectionString="data source=127.0.0.1;user id=sa; password="
cookieless="false" timeout="20" />
Once the SQL Server is configured, the application code should run identically to the InProc mode. But keep in mind that since the data is not stored in local memory, objects stored in session state will need to be serialized and deserialized for transport across the network to and from the database server, which will affect performance. By storing session state in the database, you�re effectively trading performance for scalability and reliability.
Pros and cons of the three session management solutions in brief
InProc - stored in memory on web server
This is the default setting.
- Pros: least overhead, fastest performance
- Cons: breaks web clusters, restarting IIS loses sessions
StateServer - managed by a remote service (aspnet_state)
HTTP protocol over TCP port.
- Pros: reasonably fast, works with clusters
- Cons: clear text, no authentication, overflows...
SQLServer - stored in SQL Server DB tables
Uses normal ODBC connection.
- Pros: reliable, scalable
- Cons: relatively slow, much overhead
Points of Interest
When you are upgrading an ASP application to ASP.NET, some times you may have to deal with the situation where in we need to pass state information between an ASP page and ASP.NET form. One way of accomplishing this is using cookies. Since cookies are stored in client side, when the browser requests a page, the cookie information is automatically send as part of the browser request. Because of this a cookie can be created by an ASP application and read by ASP.NET application when the browser is redirected to that ASP.NET page.
History
Version 1.1.
