C# Application and Session State
Use the "Application" and "Session" states to store data that you want to keep for the lifetime of an application
or for the lifetime of a session. you can store any type of data in the "Application" or "Session" state, including
objects. However, you should consider the following issues before using the "Application" and "Session" states:
- "Application" and "Session" state variables are created on the fly, without variable name or type checking. You
should limit your access points to these variables.
- Maintaining "Session" state affects performance. "Session" state can be turned off at the application and page levels
- "Application" state variables are available throughout the current process, but not across precesses. If an application
is scaled to run on multiple servers or on multiple processors within a server, each process has its own "Application" state.
- The Web application's boundaries determine the scope of the "Application" state.
STUCTURING ACCESS TO STATE VARIABLES
"Application" and "Session" state variables are pwerful and therfore scary things. It is easy to introduce some old-style
Basic errors in your code if you use these variables in an unstructured manner. For instance, the following code references two
different "Application" state variables:
Application["Uname"] = "Wombat";
Response.Write(Application["Unamme"]);
The first line creates a variable and stores some text in it. The second line retrieves a new, empty variable and displays nothing,
simply because the variable name is misspelled. The problem is obvious here, but if it occurred deep in a decision structure, it
would be very hard to find.
To ameliorate this problem, structure your access to "Application" and "Session" state variables. The easiest way to do this is to
declare a page-level variable for each item you need, retrieve the "Application" or "Session" state value in the Page_Load event
procedure, and save the page-level variables back to state in the Page_Unload event procedure. You might want to make retrieving
and saving state variables from a consistent location part of your coding conventions
The following code demonstrates structuring access to state variables:
public class AppSessState : System.Web.UI.Page
{
// Variable for controlling state access
string strAppState = "";
strSessState = "";
private void Page_Load(object sender, System.EventArgs e)
{
// Get Application and Session variables here.
// Check if they exist
if (Application["AppState"] != null)
strAppState = Application["AppState"].ToString();
if (Session["SessState"] != null)
strSessState = Session["SessState"].ToString();
}
private void butApp_Click(object sender, System.EventArgs e)
{
strAppState = txtValue.Text;
}
private void butSess_Click(object sender, System.EventArgs e)
{
strSessState = txtValue.Text;
}
private void AppSessState_PreRender(object sender, EventArgs e)
{
//Display Values
lblValue.Text = "Application state is: ";
lblValue.Text += strAppState;
lblValue.Text += " Session state is: ";
lblValue.Text += strSessState;
}
private void AppSessState_Unload(object sender, EventArgs e)
{
// Store values before unloading page.
Application["AppState"] = strAppState;
Session["SessState"] = strSessState;
}
}