This chapter is from the book
This chapter is from the book
This chapter is from the book
Managing Session State
Building Web sites and Web services using HTTP is inherently different than building distributed systems using protocols such as DCOM. The DCOM is a connection-intensive protocol. It often makes sense to pay attention to state for the duration of a connection. That is, if a client connects to some server somewhere using DCOM, the server may usually expect that calls coming in over the same connection are always from the same client. Therefore the client can modify the state of the server several times over the course of a connection and may know that it is modifying the same state—this is not so with HTTP.
HTTP is light in terms of connections. That is, it does not maintain connections between requests. When you surf to a URL, your Web browser connects to the server and sends the request, and the server returns a response. That is the end of the connection—it gets torn down right away. The next time you surf to the same URL (e.g., by clicking on a link), the browser sets up a new connection, sends a new request, gets a new response, and then tears down that connection.
Because of its lightweight connection nature, HTTP is a stateless protocol, meaning the server has no automatic guarantee that a string of requests is from the same client (or even the same single browser instance). This is an issue for Web applications that need to maintain state across connections. Common types of state that are often shared include the contents of shopping carts and page scrolling (so that the previous page shows up in the same scrolling position when you hit the Back button). This sort of state management can be incredibly cumbersome to program by yourself, which is why transconnection state management is built into ASP.NET.
Web servers are constantly bombarded by incoming HTTP requests. Quite often an HTTP request will come in from one client and immediately be followed by a request from a completely different client.
ASP.NET makes managing state much easier. The state management facilities come for free. Classic ASP provides two facilities for maintaining state across requests, and they are based on application scope and session scope. Session-scoped objects are bound to a particular client Web application manager (WAM) and live for 20 minutes (by default) after the last request is received. Application-scoped objects are shared by all sessions in a WAM and live as long as at least one session is alive. Each WAM directory can have a global.asa file. ASP.NET provides session-management infrastructure with built-in session-state functionality. This built-in functionality serves four main functions:
It helps you identify and classify requests coming from the same browser client into a logical application "session" on the server.
It provides a place to store session-scoped data on the server for use across multiple HTTP requests.
It raises session-lifetime management events (such as OnSessionStart and OnSessionEnd) so that you can manage the session in your application code.
It automatically cleans up the session data if the same browser fails to revisit your application after a specified time-out period.
We discuss using ASP.NET's session-state management in more detail in Chapter 8.