Server-Side State Management

Client side state management techniques enable you to store information on the client side in a lightweight fashion and are a relatively quick and easy way to do so. The problem with this approach is that for applications requiring a higher degree of security around their information, client-side state management might not be the right answer. Because server-side state management allows information to be stored on the server, there is less likelihood of this information being tampered with and it therefore poses less of a security risk.

When looking at the previous statement, you might ask yourself, "If server-side state management offers increased security, why wouldn't I use it all the time?" The answer is scalability. Although increased security is certainly a benefit, storing all the information comes at a price. Imagine a large system with approximately one million users. If every user stored the same amount of information that can be stored in a cookie (4096 bytes), the server would have to manage approximately 4 terabytes of information just for some simple user preferences. Not only is this a lot of information to store, but it can affect performance and scalability.

In the following sections, you will learn how to maintain state using the following server-side techniques: application state, session state, and using a database to store state.

Explaining Application State

Before you learn how to use the application state technique, it is important for you to understand the concept of an application in ASP.NET. An application, in ASP.NET, is all the contents (forms, code, handlers, files, and so on) that fall under a virtual directory. This includes all the subdirectories of that directory as well.

Storing Data

Storing data using the HttpApplicationState object is a relatively easy task. An instance of the HttpApplicationState class is created the first time the server receives a request for anything within the application scope and is not destroyed until the application process is terminated. The instance of the class that is created is exposed via the Application object. To use this class, simply reference the Application object as you would a hash table:

 Application["User Name"] = username.Text; 

Retrieving values is equally simple:

 userName.Text = (string) Application["User Name"]; 

Because the class returned is an object, you must cast it to the appropriate type.

TIP

Even though using HttpApplicationState class is similar to using a global variable, it is important to note that it is global to only the application process. It does not persist across web farms or web gardens. In other words, if you have an application that spans multiple processes or is run on several different machines, it is possible for each instance of the application to have different values for each name/value pairs.

Synchronizing Application State

Because an Application begins with the first request to an ASP.NET application and ends when the process terminates, it is possible to have multiple browsers and users trying to access the same variable at the same time. This could cause problems, so it is necessary to provide some sort of synchronization between the requests.

To assist with the synchronization, HttpApplicationState provides two methods: Lock and UnLock. Before writing to the state object, you should lock the object. As soon as you are done writing, you should unlock the object. The following code fragment demonstrates how to properly access an application state value. Note that the lock and unlock calls are wrapped in a resource protection block. This allows the Application object to continue to be accessed by other threads in the event of an unexpected exception while setting the value.

 Application.Lock(); try {   Application["Global Counter"] = (int) Application["Global Counter"] + 1; } finally {   Application.UnLock(); } 

Understanding Session State

Session state is very similar to application state. It allows the system to store information on the server for retrieval at a later time. Unlike the application state, session state is valid only during the current browser session. If the browser session terminates or a new session starts, the session state is either destroyed or a new one is created.

Configuring sessionState

Including being disabled, sessionState can be configured in one of four different modes: Off, InProc, StateServer, and SQLServer. This enables you to specify which method of storage to use when using sessionState.

sessionState Mode Off

When the mode is set to Off, sessionState is disabled. To turn off sessionState, simply change the mode in the configuration file to "Off".

 <configuration>    <system.web>       <sessionState mode="Off" />    </system.web> </configuration> 

sessionState Mode InProc

When the mode is set to InProc, the session information is stored locally. When using this mode, use the cookieless attribute to specify whether cookies should be used to store state information. The following example configures sessionState to be in the InProc mode, not to use cookies, and to have a timeout of 20 minutes:

 <configuration>    <system.web>       <sessionState mode="InProc" cookieless="true" timeout="20" />    </system.web> </configuration> 

sessionState Mode StateServer

When the mode is set to StateServer, the session information is stored on a remote host. When using the StateServer mode, the attributes stateConnectionString and stateNetworkTimeout must be used. The following configuration section demonstrates how to configure the server for StateServer mode:

 <configuration>    <system.web>       <sessionState        mode="StateServer"        stateConnectionString="tcpip=127.0.0.1:999"        stateNetworkTimeout="10" />    </system.web> </configuration> 

SQLServer

Placing the sessionState mode to SQLServer allows the system to store the information in a SQL Server database. When using SQLServer mode, the sqlConnectionString attribute must be used. The following configuration section demonstrates how to configure the system to use SQLServer mode:

 <configuration>    <system.web>       <sessionState mode="SQLServer"         sqlConnectionString="data source=localhost;Initial Catalog=testdb" />    </system.web> </configuration>