At this moment I'm busy with an ASP.Net application in C#, for a customer. We came across the problem that we need to save the Dataset information on the client side, because otherwise we always need a round trip to the server and that's something we don't want tot do. The data need to be saved contains maximum around 20 records. State management will do this for us.

State management involves storing temporary information that is important to the current users. It only applies to web applications that need to keep track of users, authorization and page flow.

State management information is information that is only needed temporarily to enable the system’s functionality. It is not ‘permanent data’ as with e.g. databases. State management be divided into three components:

• Information about the current session for a single user
• Information about the web application for all users\
• Information about page flow and page data Several options are possible.

We will write them down with the advantages/disadventages.

Sessions info

Quick guidelines

• Restrict ViewState information to non-sensitive data that is needed on one page only
• When using the Session object, preferably use objects that are serializable as these objects can be migrated to other session state variants
• Use InProc session state for simple web applications
• When possible, use session state with server affinity for a web farm
• Use server session state or database session state for web farms where server affinity is not possible

ViewState

ViewState is a system where data is encoded and sent along as HTML towards the client and subsequently returned with the next request. The information is visible as encoded text in the web page’s source. ViewState is supported by .Net server controls and can be custom-implemented. ViewState operates fully stateless, eliminating the need to store data on the web server. Since extra information is sent to the client and back to the server, possible performance issues may arise.

Pro:

• No server resources are used · Fully stateless, so easily scalable
• Easy implementation

Contra:

• Large amounts of data transport between client and server may cause performance issues
• Problems may arise regarding security because sensitive information is passed on
• ViewState cannot be used to enable information interchange between pages

InProc Session State

InProc session state is a system where session data is kept in a Session object. This object is managed in the server’s memory.

Pro:

• Easy implementation
• Expandable towards other session state variants (in principle)
• The Session object is available throughout application

Contra 

• Session data takes up server resources
• Not readily scalable to multiple machines

Session state with server Affinity

Session state with server affinity involves keeping data in a Session object. This object is managed in the server’s memory. The server affinity will cause a subsequent request to be routed to always the same server, solving the problem of scalability.

Pro:

• Easy implementation from the developer’s point of view (no extra effort needed)\
• The Session object can be used for multiple machines
• The Session object is available throughout the application

Contra:

• External configuration of the server environment is needed
• Session data takes up server resources

Session State Server

A session state server is a system that keeps data in the memory of a specially installed server. This server is accessible for all other servers within a web farm. Actions may be performed on the Session object from within the web application, implicitly making use of the state server.

Pro:

• Easy implementation from the developer’s point of view
• Scalable to multiple machines
• Configurable through configuration files

Contra:

• Data must be serializable
• Requires a specially equipped machine
• Performance is lower compared with a standard session object

Database Session State

Database session state involves keeping data as serialized data in a dedicated SQL Server database.

Pro:

• Easy implementation from the developer’s point of view 
• Scalable to multiple machines 
• Configurable through configuration files

Contra:

• Data must be serializable 
• Only possible in combination with SQL Server 
• Performance is lower compared with a standard session object

Application info

Quick guidelines

Application information is general data intended for all users. No session data or data that is to be shared between pages is involved.

• When working with application state, use infrequently changed serializable data as much as possible
• When possible, use caching as this eventually frees resources
• Use the Application object when data is to be continually present
• Never use static variables for application state

The Application Object

For each web application, there are situations where you want to share information with all of its users. Application state is a system where such data is maintained within an Application object. This object is kept in the server’s memory.

Pro:

• Easy implementation
• Application state variables are accessible throughout the application to all users

Contra:

• Data is not persistent. Application data is lost in case of a fatal hardware or software failure
• Application data takes up server resources
• There is no guarantee that application state data is unique within a web garden or web farm environment, since this data is not shared · Within a multi-threaded environment, locking is to be implemented to prevent deadlocks and access violations

Static Variables

Within a web server, static variables are available to all web pages. These variables can be easily approached by all code.

Pro:

• All Application object advantages apply here as well

Contra:

• No guarantee that data is still present when calling upon it
• Potential issues with the ASP.Net standard multi-threading system
• Frequent re-starting of the application may cause problems in the application’s development phase

The Cache Object

ASP.Net supports the Cache object, where information may be stored that is needed for a certain amount of time.

Pro: 

• Data may be cleared after a certain amount of inactivity

Contra:

• It may be possible that data has to be re-fetched as this object has automatic management

Inter-page state

Quick guidelines

In a web application the situation frequently arises that data that is entered or present on a given page is to be passed onto another. This phenomenon is different from session state because this data is only needed in memory at the moment of page transfer.

• Use the Server.Transfer method and HTTPContext to transfer state between pages
• Use query strings for simple data that does not have to be secure
• Use a single, compound page for a ‘wizard’-like solution
• Use session state when all other options are out
• Avoid using cookies to store inter-page state

Compound Pages using ViewState

A compound page is a single page that has been divided into several sections. This page may function as a ‘wizard’, where different sections of a page are shown piece by piece. This way, the information of the ‘previous page’ (in reality, the previous section of the same page) is available through ViewState.

Pro: 

• Ease of use

Contra: 

• Only suitable for wizard-like applications
• Lower performance because all sections are loaded, even when they are not visible

Session State

The Session object may also be used to transfer state between pages. When re-posting the page, new information may be placed in the Session object and control may be released to another page (by means of the Response.Redirect or Server.Transfer methods). On loading, the target page may obtain the information from the Session object.

Pro: 

• Ease of use

Contra:

• There is no guarantee that the desired information is present in the Session object. Validation is necessary to check this
• The information is not type-safe 
• During the time-out period, the data remains available, unnecessarily taking up server resources 
• A Response.Redict results in an extra round trip

Query String

This is a method in which arguments are passed on to the target page by adding text to the URL.

Pro: 

• Easy implementation 
• No server resources are required

Contra: 

• The amount of data that may be passed on is limited
• The data is visible in the browser and can be modified by the user. This may cause security issues
• Provokes the use of client-side scripting · Only works with HTTP Get requests

Using server.transfer and httpcontext

This technique involves a page performing a HTTP Post request to itself and redirecting this request to another page through the server by means of the Server.Transfer method. At this new page, the old one is still visible through Context.Handler. Moreover, arguments may be passed on using the Items collection of HttpContext.Current.

Pro: 

• Makes type-safe passing-on of arguments possible
• Not dependent on server or client state
• No redirect to the client necessary

Contra: 

• Complex implementation
• The URL shown in the browser does not match the page shown in its window

Cookies

Cookies allow for storing small amounts of information at the client. No data is passed on between pages, but information is centrally available to all pages. This makes information sharing between pages possible.

Pro: 

• No server resources needed
• Easy implementation 
• Configurable expiration 
• Also suitable for fixed HTML that contains no server functionality

Contra: 

• The amount of data is restricted to a maximum of 8192 bytes (8 kilobytes) per cookie
• Data is visible to and modifiable by the client, making it a security risk
• A client may refuse or delete cookies
• Fixed HTML without server functionality will need client-side scripting to be able to read cookies

We have choosen for the Cache object. 

References

- Visual Basic and Visual C# ConceptsState Management Recommendations
- Caching Architecture Guide for .Net Framework Applications