.

.

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.

TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

Show/Hide comments

Show/Hide comment form