ASP.NET Application State Overview
Application state is a data repository available to all classes in an ASP.NET application. Application state is stored in memory on the server and is faster than storing and retrieving information in a database. Unlike session state, which is specific to a single user session, application state applies to all users and sessions. Therefore, application state is a useful place to store small amounts of often-used data that does not change from one user to another. For information on saving data on a per-user basis see ASP.NET Session State Overview and ASP.NET Profile Properties Overview.
Using Application State
Application state is stored in an instance of the HttpApplicationState class. This class exposes a key-value dictionary of objects.
The HttpApplicationState instance is created the first time a user accesses any URL resource in an application. The HttpApplicationState class is most often accessed through the Application property of the HttpContext class.
You can use application state in two ways. You can add, access, or remove values from the Contents collection directly through code. The HttpApplicationState class can be accessed at any time during the life of an application. However, it is often useful to load application state data when the application starts. To do so, you can put code to load application state into the Application_Start method in the Global.asax file. For more information see ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.0.
Alternatively, you can add objects to the StaticObjects collection via an <object runat="server"> declaration in your Web application's Global.asax file. Application state defined in this way can then be accessed from code anywhere in your application. The following example shows an object declaration for an application state value:
<object runat="server" scope="application" ID="MyInfo"
PROGID="MSWC.MYINFO">
</object>
You can add objects to the StaticObjects collection only in the Global.asax file. The collection throws a NotSupportedException if you attempt to add objects directly through code.
You can access members of objects stored in application state without having to reference the Application collection. The following code example shows how to reference a member of an object defined in the StaticObjects collection of application state. Notice that the label identifier that is defined in the Global.asax file is used as the variable name.
Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs)
Label1.Text = MyInfo.Title
End Sub
protected void Page_Load(Object sender, EventArgs e)
{
Label1.Text = MyInfo.Title;
}
Application State Considerations
When using application state, you must be aware of the following important considerations:
Resources Because it is stored in memory, application state is very fast compared to saving data to disk or a database. However, storing large blocks of data in application state can fill up server memory, causing the server to page memory to disk. As an alternative to using application state, you can use the ASP.NET cache mechanism for storing large amounts of application data. The ASP.NET cache also stores data in memory and is therefore very fast; however, ASP.NET actively manages the cache and will remove items when memory becomes scarce. For more information see ASP.NET Caching Overview.
Volatility Because application state is stored in server memory, it is lost whenever the application is stopped or restarted. For example, if the Web.config file is changed, the application is restarted and all application state is lost unless application state values have been written to a non-volatile storage medium such as a database.
Scalability Application state is not shared among multiple servers serving the same application, as in a Web farm, or among multiple worker processes serving the same application on the same server, as in a Web garden. Your application therefore cannot rely on application state containing the same data for application state across different servers or processes. If your application will run in multi-processor or multi-server environments, consider using a more scalable option, such as a database, for data that must preserve fidelity across the application.
Concurrency Application state is free-threaded, which means that application state data can be accessed simultaneously by many threads. Therefore, it is important to ensure that when you update application state data, you do so in a thread-safe manner by including built-in synchronization support. You can use the Lock and UnLock methods to ensure data integrity by locking the data for writing by only one source at a time. You can also reduce the likelihood of concurrency problems by initializing application state values in the Application_Start method in the Global.asax file. For more information see ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.0.
See Also
Tasks
How to: Save Values in Application State
How to: Read Values from Application State
Concepts
ASP.NET State Management Overview