In my last article I explained about client-side state management where the client, i.e. your browser preserves the state. In this article we will have a look at server side state management. There might arise a scenario where you want to have your state encrypted and secure or you might want to preserve state globally across your application. In such a situation you use server-side state management.
ASP.Net provides two ways to store state on the server:
- Application state - The information is global o the application and is available to all users regardless of the identity of the user requesting the page.
- Session state - user specific state that is stored on the server. It is available on a user basis who is visiting your site.
Application state is a global storage mechanism for your application for data that needs to be available for your entire application. You can use application state to store information that must be maintained between requests. A product catalogue which does not change very often can be considered for application state. You can think of application state as a form of application level caching of data which is hard to obtain.
Application state us stored in an instance of HttpApplicationState class available through the Page.Application property. This class represents a key-value pair where data is stored as key-value pairs. You can write into and read from application state. Once data is added to application state the server manages it.
Application state is a great place to store data when you don’t want to track users and require your data to be available for the entire application. All pages can access data from a single location rather than having multiple copies of it serving each request.
Data stores in ASP.Net application is not permanent. It is lost when your application is restarted or your web server restarts.
Care should be taken not to store sensitive information in application state as it is global to your application.
Global.asax and Application events
The HttpApplication class provides you with several events that you can handle to perform actions at application level. These can include anything like initialising variable, logging requests, handling application level errors etc. The events are implemented in a file called Global.asax file, also known as Global Application Class. Here are some of the common events you would find in a Global.asax file. When the files are added to your Visual Studio project the event stubs are created by Visual Studio.
Listing 1: Some of the common application level events
||When ASP.Net raises the event? Usage
||Application is started upon a user request. Variable at application level can be initialised here
||Application stops or shuts down. Code to free local resources can be written here
||An unhandled exception occurs which rises to application level. Can be used for catch-all error logging
||Request has been made to application. Can be used to log custom logging information
||After logging of request complete.
How to read and write Application-state data
Application collection can be used to read and write data into application state. Because there might be number of users accessing your data, care should be taken to lock the Application object before writing data to it .Otherwise changes can be made to the data by another page between the time the first page reads the data and updates it.
Listing 2: How to write data into Application State
void Application_Start(object sender, EventArgs e)
You need not lock the Application object before you read it. However, you must cast the data to the correct type before using it as the data is stored as an object value in Application state. You should also add a check to ensure that the data is not null.
Listing 3: How to read data from Application State
string message = Application["Message"] as string;
Most of the web applications today need to store user-specific data between individual requests. Imagine a user on your website trying to shop and add products into shopping basket. This requires data to be temporarily available between pages until user has completed the process. In this case you can use the ASP.Net process to store data in the server memory and this is called session state.
Session state is very similar to application state except for the fact that the data is scoped to the current user rather than all the users and is available only to that session. Each user on your website will have an isolated session running in the memory of the server. The information is available as a user traverses through multiple pages on the website. As soon as the session times out or user closes the browser the data is lost.
Reading and writing session data
Session object is used to store session state. This is an instance of HttpSessionState class and represents a key-value dictionary collection.
Listing 4: Write data to session state
Listing 5: Read session state
If(Session[“lastvist”] != null)
You should always ensure that session is not null and cast the data to correct type before using it.
Responding to session events
You can respond to session events using the events available in Global.asax files. Some of the most common events are listed below.
Listing 6: Session events
||When a new session starts. Session variables can be initialised here
||When a session ends or time out. Used to free up per-user resources or log information
Configuring cookieless session
If browser cookies are enabled, ASP.Net saves a cookie to the client to track session. The cookie is called ASPNet_SessionId and contains a random 24-byte value. This cookie is submitted with a request and ASP.Net maps a session to this cookie. If cookies are disabled on a browser ASP.Net uses the url to track session. It embeds a session id after the application anme and before any remaining virtual directory name of the file name.
Cookieless sessions can be enabled in the web.config file by setting the cookieless attribute of the sessionstate element to true.
Disabling session state
Session state can be disabled site wide by setting mode attribute of the sessionstate element to Off. You can also enable session state on a per page basis by setting the EnableSessionState directive to true. If it is specified ReadOnly the page will only have read-only access to session state.