Everything you wanted to know about State Management in ASP.NET

Introduction

As most of us know that web pages are stateless and are HTTP-based, which means that it does not automatically indicate whether a sequence of requests is all from the same client or a new Client or even worst whether a single browser instance is still viewing the site. Every time a client requests a page, a new instance of the page is returned and after each roundtrip the page is destroyed. So in nutshell, state is not maintained between client requests by default.

Applications ranging from huge shopping sites to small intranet sites depend on the ability to track individual requests from distinct users and store state on behalf of each user, say for e.g., some preferences selected by user. Right from the days of Classic ASP, there are various technologies available for state management. ASP uses cookie, query string, application, session etc. ASP.NET supports all these along with some richer, easier and more powerful mechanisms, which can be used to build robust web applications. ASP.NET not only greatly simplifies the process, but also solves some of the classic ASP Session object's problems like using Sessions with Web farms or web gardens scenarios.

State Management Options

In a broader view there are two ways to manage web page�s state. It could be on Client-side and could be on Server-side. Both of these are used depending on the implications and requirements.

First we will look into the client side state management options.

Client-side state management: Under Client side state management no information is maintained on the server between round trips. Information will be stored in the page or on the client�s computer.

The following are the various ways in which Client side state can be maintained:

• Cookies
• Hidden Fields
• View State
• Query Strings

Cookies: A cookie is a small amount of data stored either in a text file on the client's file system or in-memory of the client browser session. Cookies are mainly used for tracking data settings. Although cookies are typically used to store user-specific configuration information and preferences, they can be used to store any client-specific state needed by an application (as long as that state is converted to string format) An example could be to customize the welcome page based on the user preferences.

The following is an example of using Cookies in ASP.NET:

HttpCookie nameCookie= new HttpCookie("Name");
nameCookie.Value = TxtName.Text;
Response.Cookies.Add(nameCookie);

Hidden Field: A hidden field does not render visibly in the browser, but you can set its properties just as you can with a standard control. When a page is submitted to the server, the content of a hidden field is sent in the HTTP form collection along with the values of other controls. ASP.NET provides the HtmlInputHidden control that offers hidden field functionality.

Following is the code example in C#:

protected System.Web.UI.HtmlControls.HtmlInputHidden Hidden1; 
//To set a value 

Hidden1.Value=�Test Value assigned to hidden field�; 
//to retrieve a value 

string strValue=Hidden1.Value;

Although its name is �Hidden�, its value is not hidden; you can see its value through �view -> source� option in the browser.

View State: In addition to session state and cookie state, ASP.NET introduces the ability to store client-specific state through a mechanism called view state. View state is stored in a hidden field on each ASP.NET page called __VIEWSTATE. Each time a page is posted to itself, the contents of the __VIEWSTATE field are sent as part of the post. The primary use of view state is for controls to retain their state across post-backs.

The following is an example of using ViewState in C#:

//to save information 

ViewState.Add(�Test�,�ViewState Sample�); 
//to retrieve information 

string test=ViewState[�Test�];

Query Strings: Query strings provide a simple but limited way of maintaining some state information. You can easily pass information from one page to another, But most browsers and client devices impose a 255-character limit on the length of the URL. In addition, the query values are exposed to the Internet via the URL and so in some cases security may be an issue. A URL with query strings may look like this: http://www.Himanshu.com/list.aspx?Age=27&Count=101. When list.aspx is being requested, the category and product information can be obtained by using the following codes:

[c#] string Age, Count; 
Age =Request.QueryString[�Age�]; 
Count =Request. QueryString [�Count�];

Server-side state management

In case of Server Side State management, the information will be stored on the server, the good part is that it has higher security but it can use more web server resources. The Server Side State management can again be distributed under two subheads: In Process State Management and Out of Process State Management. In Process State Management talks about Application and Session objects while Out of process State Management talks about storing state in SQL Server or State Server provided by .NET. Let us explore each one of them in detail.

In Process State Management Configuring In-process Mode

In-process is the default session state mode. To use in-process mode, set the mode attribute of the <SESSIONSTATE> element to Inproc. The following shows a sample configuration setting for in-process mode:

<configuration>
   <system.web>
      <sessionState mode="Inproc" cookieless="false timeout="20"/>
      </sessionState>
   </system.web>
</configuration>

Application object

The Application object provides a mechanism for storing data that is accessible to all code running within the Web application. The information that is global to the application may be stored in application objects. For efficiency, this state is typically stored once and then read from many times. There are various issues, which a programmer should consider before using Application Variables. The programmer should consider issues like memory occupation, concurrency and synchronization implications of storing and accessing a global variable within a multithreaded server environment, the scalability of Application level variables as they can not be shared across a Web farm (in which an application is hosted by multiple servers) or a Web garden (in which an application is hosted by multiple processes on the same server).

In spite of these issues, well-designed application-level variables can be very powerful in Web applications. You can do a one-time (or infrequent) loading and calculation of information and then use application state to cache it for speedy, in-memory access during later Web requests.

Session object

Session object can be used for storing session-specific information that needs to be maintained between server round trips and between requests for pages. Session object is per-client basis, which means different clients generate different session objects. The ideal data to store in session-state variables is short-lived, sensitive data that is specific to an individual session. Each active ASP.NET session is identified and tracked using a 120-bit SessionID string containing URL-legal ASCII characters. SessionID values are generated using an algorithm that ensures uniqueness and SessionIDs are generated on random basis, which makes it harder to guess the session ID of an existing session. Depending on the configuration settings, the SessionIDs are communicated across client-server requests either by an HTTP cookie or a modified URL.

The following is an example of storing Session value in ASP.NET:

//to store information Session[�UserName�]=�Himanshu�;

//to retrieve information myname=Session[�UserName�];

Storing Session State out of Process

ASP.NET introduces the ability to store session state out of process, which can be set using the sessionState element in an ASP.NET application's web.config file. The default location is in-process, as it was in classic ASP. If the mode attribute is set to StateServer or SqlServer, however, ASP.NET manages the details of saving and restoring session state to another process or to an SQL Server database. This is appropriate because it is possible to build ASP.NET applications that access session state in the normal way, and then by switching the sessionState mode in a configuration file, that same application can be deployed safely in a Web farm environment.

Storing State in SQL Server Database

One of the widely used options for storing session state outside the server process is to keep it in an SQL Server database. ASP.NET supports this through the SQLServer mode in the sessionState configuration element in web.config file. For using this mode, you must run the InstallSqlState.sql script on the database server where session state will be stored. This script can be found in the main Microsoft.NET directory. As soon as you run the script, it creates a table that can store client-specific state indexed by session ID in the tempdb of that SQL Server. The ASP state table is created in the tempdb database, which is not a fully logged database, thus increasing the speed of access to the data.

Following is an example of configuring web.config file to use SQL Server:

<configuration>
   <system.web>
      <sessionState mode = "SQLServer" 
            "data source=192.168.1.103;user id=sa;password=" />
      </sessionState>
   </system.web>
</configuration>

Database enables you to store large amount of information pertaining to state in your Web application. Sometimes users continually query the database by using the unique ID, you can save it in the database for use across multiple request for the pages in your site.

The ASP.NET State Service

The State Service can run either on the same machine as the Web application or on a dedicated server machine. The .NET Framework provides aspnet_state.exe that could be used as a service to maintain state. Using the State Service option is useful when you want out-of-process session state management but do not want to have to install SQL Server on the machine hosting the state.

Following is an example of configuring web.config file to use State Server:

<configuration>
   <system.web>
      <sessionState mode="StateServer" stateConnectionString="10.1.1.29:23454"/>
      </sessionState>
  </system.web>
</configuration>

Conclusion

In this article, I have tried to give a complete overview of the state management options provided in .NET. Though ASP.NET has more functions and utilities than ASP to enable you to manage page state more efficiently and effectively, the developer should consider all the pros and cons of using them and take some time to decide which one would be best applied to the application. The following are the issues, which a developer should think about before making any choice.

• How important is the information?
• The amount of information or the data, which needs to be stored.
• Whether persistent or in-memory cookies can be used with the Client?
• The place where the information will be stored, i.e., the Client or the Server.

Considering all these, let's try our best to unleash the power of ASP.NET in the most efficient and elegant way.