ASP.NET Customizing the Session State Mechanism
In this tutorial you will learn about Extending the Session State Mechanism, The Default Session State Mechanism and its customization, Customizing the Session State Module and Writing a custom session state module
Extending the Session State Mechanism
The stateless HTTP protocol treats each page request independently and the server is unaware of the variable values of the earlier request. The session state is a dictionary based API that is used by developers to store user specific data for the duration of the session. The session state is enabled by default for all ASP.NET applications. In ASP.NET 2.0 developers can define custom stores for session states or customize session states in the existing ASP.NET session state mechanism. In the latter the customizable options are limited whereas in the former the developer has greater flexibility. In this section we shall examine both these options in great detail.
The Default Session State Mechanism and its customization
By default session variables are stored in a SessionStateItemCollection that is exposed through the System.Web.HttpContext.Session property. The collection is indexed by the name of the variable
Session["FirstName"] = FirstNameTextBox.Text;
Session["LastName"] = LastNameTextBox.Text;
The session variables can be of any valid .NET type such as ArrayList. Session identifiers are read using the SessionID property. Each page request is examined for a SessionID value and a new session starts only if no SessionID value is found. These values are stored in a cookie by default. However, the applications can be configured to store SessionID values in the URL as a cookieless session. Each session is active until the SessionID is terminated or timed out.
Session Events are raised when a new session is started or a session ends. The Session_OnStart event and Session_OnEnd events are raised at the start and end of the session respectively. These events are specified in the Global.asax file(web.config file) in the ASP.NET application. The session_OnEnd event is not supported if the session mode value is not set to InProc (the default mode).
The session mode defines the different storage options available for storing session variables. By default session variables are stored in the memory space of the ASP.NET worker process. The storage can be customized and the session mode can be set to off at the option of the developer.
The session state can be configured using the
he sessionState is exclusive to the session in ASP.NET. When two different users make concurrent requests to a page, separate sessions are granted concurrently. If two requests are made for a single sessionID, then the first request is granted exclusive access while the second request will be executed on release from the first request. If the request is for a readonly session mode then the both requests are granted simultaneously. However read write request will dominate a read only request and the latter must await the release of the sessionID by the former.
Customizing the Session State Module
Four aspects of the session state module can be customized by the developer. The first of these is the Session Data Store. This is a layer of code that reads and writes the session data to a particular storage medium. ASP.NET 2.0 allows the developer specify his data store. The session data store class inherits fom the SessionStateStoreProviderBase class. It has a number of methods that can be manipulated.
The BeginRequest is fired when the session begins and is called by default by the AcquireRequestState event.
The CreateNewStoreData creates a new object to contain all the state information specific to a session. It returns an object of the type SessionStateStoreData.
Dispose releases all the resources used by the session data store object.
EndRequest is called by default to end a session state module.
GetItem gets the session data from the data store. It serves requests from applications that use read only session state.
GetItemExclusive gets the session data from the data store and locks it for any request that has readwrite privilege.
Init receives the object packed with the configuration settings for a custom session state and initializes the provider class.
ReleaseItemExclusive unlocks the session state item by a call to the GetExclusive method. RemoveItem removes the session data store item from the session data store.
ResetItemTimeout resets the expiry time of a session state object based on the session’s timeout value.
SetAndReleaseItemExclusive writes a session data item to a data store.
SetItemExpireCallback calls this method to notify the data store class that the caller has registered a Session_OnEnd handler.
The sessionState configuration section can be modified to take advantage of the custom session data providers. The code would look as under:
< sessionState mode=”custom”
CustomType=”Samples.MyDataStore.MyDataStoreLib” >
.
.
.
< / sessionState >
Based on the above script ASP.NET will use the Samples.MyDataStore class to access the session data. This class is loaded into the MyDataStoreLib assembly.
The next aspect that can be customized is the Session State Item. The default session state item is named SessionStateStoreData. A custom class can be inherited from this class to create a custom session data store item.
The third aspect of the default session state module that can be customized is the Session Data Dictionary. The dictionary is a component of the SessionStateStoreData class and contains the user defined items. The Items collection is actually exposed to the page through the Session property. By default it is an instance of the HttpSessionState class. This default dictionary can be replaced by a custom one by creating a class that implements the ISessionSessionItemCollection Interface.
The last aspect of the session state module that can be customized is the generation of the session ID. ASP.NET 2.0 uses the HTTP module SessionIDModule to generate the session ID. It implements the ISessionIDModule interface. This module can be replaced with a custom module. This module should be registered in the configuration file by using the following code:
< httpModules >
< remove name=”SessionID” / >
< add name= “MySessionID” type=”Samples.MyIDModule.MyLib” / >
< / httpModules >
It must be noted that the default session ID Http module will have to be removed before the custom module is added to the configuration file.
Writing a custom session state module
Manipulating an existing default module is easy compared to writing a custom session state module. The developer has to write all the key application events—AcquireRequestState, ReleaseRequestState and EndRequest.
The module will first have to be initialized using the Init and Dispose methods of the IHttpModule. In the Init method the developer will have to read the configuration information from the web.config file and then configure the state of the module and prepare it for handling the custom configuration. The application events are subscribed to in the Init method and a reference to the session Id is obtained. Look at the following code:
ISessionIDModule idModule;
HttpApplication app=Httpcontext.Current.ApplicationInstance;
idModule=SessionStateUtility.GetSessionIDModule(app);
In the above instance the reference to the currently loaded module is obtained.
The AcquireRequestState event helps retrieve the sessionID for the request by calling the GetSessionID method. The developer must take into consideration cookies or implement alternate schemes to store session IDs. If no session Id is found a new id is generated to the Response object by calling SaveSessionID on the ISessionIDModule interface. Once the session ID is retrieved the module connects to the data store and retrieves the associated data. The session state object is now created and bound to the current context and made available to applications through the sessions property. If this is a new session the developer will have to fire the Start event.
Once the session state is to be terminated, the ReleaseRequestState event is to be fired. The session state object should be detached from the HTTP context and saved back into the data store. If the session state is empty a new session will have to be created and this aspect will have to be customized by the developer. Support for Session_OnStart and Session_OnEnd should be created using the name Session and it should be registered in the custom module as such. The following code can be used to replace the session module:
< httpModules >
< remove name= “Session” / >
< add name = “Session” type= “Samples.MySession.MyLib” / >
< / httpModules >
In this section of the tutorial we have studied how to manipulate the default session modules and also create custom session modules. In the next section we will examine the ASP.NET Cache object and its features.
