Programming Microsoft ASP.NET 4 - Dino Esposito [350]
The extensibility model for session state offers two options: customizing bits and pieces of the existing ASP.NET session state mechanism (for example, creating an Oracle session provider or a module controlling the generation of the ID), and replacing the standard session state HTTP module with a new one. The former option is easier to implement but provides a limited set of features you can customize. The latter option is more complicated to code but provides the greatest flexibility.
The Session-State HTTP Module
Regardless of the internal implementation, the programmer has only one application programming interface (API) for session state management—the old acquaintance known as the Session object. In classic ASP, it was a COM object that was instantiated in the asp.dll ISAPI extension and injected into the memory space of the ActiveX Scripting engine called to parse and process the .asp script. It is a collection object in ASP.NET, living behind the Session property of the Page class. The exact type is HttpSessionState; it’s a class that’s not further inheritable and that implements ICollection and IEnumerable. An instance of this class is created during the startup of each request that requires session support. The collection is filled with name/value pairs read from the specified medium and attached to the context of the request—the HttpContext class. The Page’s Session property just mirrors the Session property of the HttpContext class.
If developers can simply work with one object—the Session object—regardless of other details, most of the credit goes to an HTTP module that governs the process of retrieving and storing session state with some help from special provider objects. The ASP.NET module in charge of setting up the session state for each user connecting to an application is an HTTP module named SessionStateModule. Structured after the IHttpModule interface, the SessionStateModule object provides session-state services for ASP.NET applications.
Although, as an HTTP module, it is required to supply a relatively simple programming interface—the IHttpModule interface contracts only for Init and Dispose methods—SessionStateModule does perform a number of quite sophisticated tasks, most of which are fundamental to the health and functionality of the Web application. The session-state module is invoked during the setup of the HttpApplication object that will process a given request, and it’s responsible for either generating or obtaining a unique session ID string and for storing and retrieving state data from a state provider—for example, SQL Server or the Web server’s memory.
State Client Managers
In ASP.NET, there are four possibilities for working with the session state. The session state can be stored locally in the ASP.NET worker process; the session state can be maintained in an external, even remote, process named aspnet_state.exe; and the session state can be managed by SQL Server and stored in an ad hoc database table. The fourth option entails you storing the sessions in a custom component. Table 17-4 briefly describes the various options. Table 17-4. State Client Providers Mode Description Custom The values for all the sessions are stored in a custom data store. InProc The values for all the sessions are maintained as live objects in the memory of the ASP.NET worker process. This is the default option. Off Session state is disabled, and no state client provider is active. SQLServer The values for all the sessions are serialized and stored in a SQL Server table. The nstance of SQL Server can run either locally
When invoked, the session-state HTTP module reads the settings in the