ASP.NET provides a framework for storing data that is specific to an individual user with the Session object. A page can add information to the Session object, and any other page can then retrieve the information for the same user. In order to preserve server memory, ASP.NET implements a rolling timeout mechanism which discards the session information for a user if no request is seen within the timeout period (default 20 minutes which is reset with each request).
It is often useful in an ASP.NET site to know for a particular request if the user’s session information is still intact (that a timeout has not occurred). One common need is to be able to inform the user why they lost their session information, by redirecting to a page that describes the timeout amount and how to avoid the problem in the future. Without this technique it is difficult to know if a session variable is not present whether it was never set properly or the user waited too long between requests. Many ASP.NET developers just reference session variables without first ensuring they are actually present. This causes the infamous "Object reference not set" exception, which can be very difficult to trace back to the specific cause. Code that checks for null session values is useful, but does not help the developer understand if it was never set properly or if the user just lost her session. This technique can help to clearly identify that the user waited to long between requests and the session storage information was removed.
This is not the same as using the Session_OnEnd event which can be used for cleanup, logging, or other purposes. It is also not for enforcing security on a web site.
How Sessions Are Implemented
Since the HTTP protocol used by web browsers to request files from web servers is stateless, ASP.NET needs to determine which requests were from the same user. The primary mechanism utilizes a non-persistent cookie that is issued by the web server that contains a session id value. The id provided by this cookie is the key used to index into the session infrastructure to access the user's specific data. The session framework is implemented by the HTTP module System.Web.SessionState.SessionStateModule, which executes before the .aspx page events. The module uses the EnableSessionState attribute from the @Page directive to determine if it must retrieve the user’s session information (and whether it needs to write out changes when the request is complete). If the EnableSessionState attribute is true (which it is by default), the module retrieves all of the user’s session information and sets the Session property of the Page class to an instance of the HttpSessionState class. This article focuses on the cookie mechanism, although a cookie-less method of sessions is implemented in ASP.NET (the session id is embedded in the URL string). The Session information can be stored in-process (default, stores in web server memory), with a state service, or a SQL Server database. This article will focus on the in-process storage, but the technique applies to all three locations.
Example User Session
A user opens a browser instance and requests an ASP.NET page from a site. If the EnableSessionState attribute is true, the session module adds the ASP.NET_SessionId cookie to the response. On subsequent requests to the same web site, the browser supplies the ASP.NET_SessionId cookie which the server side module uses to access the proper user’s information.