Server side State Management : Application Object

Server side State Management : Application Object

Data stored in session is not permanent and data stored is usually only available to specific user. The Application object stores data that is shared across the application and not for a specific user. All data stored in Application in stored in asp.net process means if you restart your application all data in lost. Application state is stored in an instance of the HttpApplicationState class. This class exposes a key-value dictionary of objects. Internally the values of both the Session and Application objects are stored in a key/value pair (HashTable).


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 all 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.

ASP.NET provides following events that are related Application variables :

a. Application_Start: Fired when the first instance of the HttpApplication class is created i.e. Raised when the application starts.It allows you to create objects that are accessible by all HttpApplication instances perfect place to initialize Application variables.

b. Application_End: Fired when last instance of the HttpApplication class is destroyed in short when Raised when an application close down. Use this to free application resources and perform logging like Finally in Try-Catch !!! This is fired Once only during the lifetime of the Application.

c. Application_Error: Fired when an unhandled error/exception occurs.

Advantage of Application Object State :
Application Object is stored in memory, application state is very fast compared to saving data to disk or a database.

Drawbacks of Application Object State :

  • storing large blocks of data in application state can fill up server memory, causing the server to page memory to disk.
  • As application state is stored in server memory, it is lost whenever the application is stopped or restarted.
  • We always need to access data in thread safe manner( using Lock(0 & UnLock() ) when many applications are accessing it.

    Detail Explanation from MSDN

    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.

    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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s