History of Session State

Microsoft Active Server Pages (ASP) first introduced the server-side programming model of session state. The Session object model has properties that are accessible within ASP and are used to store and manage user state data that needs to be persisted between browser requests. The programming model is a simple dictionary-style API in which all access is controlled through a known key. State data, such as the URL of the last page visited or the last 10 search requests, can be persisted using a key and retrieved using a key. For example, the following Visual Basic code works in both ASP and ASP.NET:

 ‘ Set a session value for last page visited
Session("LastPageVisited") = "http://www.asp.net/default.aspx"
 
‘ Get a session value for last page visited
lastPageVisited = Session("LastPageVisited") 

Limitations with ASP Session State

Despite the advantages of ASP, ASP session state has three significant limitations: server affinity in Web farms, apartment model threading, and the HTTP cookie requirement. It was primarily for these three reasons that many developers avoided ASP session state.

Server Affinity in Web Farms

Prior to ASP.NET, server farms that supported session state required smart network hardware to ensure that a client was always redirected to the Web server initiating the first request. In ASP, the session data is stored within the Microsoft Internet Information Services (IIS) process that created it.

ASP runs as an ISAPI extension in the memory space of the IIS Web server. Data stored in memory by ASP is bound to that Web server process and can’t be shared between servers. This limitation requires the client always to use the same Web server to guarantee consistency of its session state data. For example, if a user set data in session on server A and used server B on the next request, the session created on A would not be available data.

This connection of the client to a particular server is known as IP affinity, and it is a requirement for using session state. (There are other internal redirection solutions, but IP affinity is the most prevalent.) This solution usually requires complex networking hardware to load-balance the traffic. It relies on the client reusing the same IP address on multiple requests and the router maintaining a table of client IPs to server IPs. Routers then intelligently reroute requests based on the mapping of client IPs to server IPs, guaranteeing that the client goes back to the server it started with.

However, even with this IP affinity solution in place, many applications still failed to properly account for large Internet Service Providers (ISPs) such as AOL, MSN, and EarthLink. These three ISPs were the most well known for using reverse proxies for their clients, which meant that on each request the client could come from a different IP address.

Apartment Model Threading

Another limitation of ASP session state is that apartment model–threaded components are the de facto COM threading model. COM servers stored in session state cause multiple simultaneous requests to the same session value to be serialized. This problem is also common with ASP application state.

HTTP Cookies Requirement

ASP session state is also bound to an HTTP cookie. (You’ll learn more about cookies later in this chapter.) When a new session starts, ASP assigns an HTTP cookie to the client; the cookie contains a unique key that the client and server share. This key, known as SessionID, is a unique value that the server generates and uses to associate session data with the client that posts the key. The IP address can’t be used for this since the IP address can potentially change on each request.

Using an HTTP cookie works very well until a client decides not to accept cookies. In many cases this restriction breaks application functionality; since the client can’t maintain a SessionID, the application can’t rely on session state.