Application State in ASP.Net (2024)

Introduction

Application State is a state management technique. Application State is stored in the memory of the the server and is faster than storing and retrieving information in a database. Session sate is specific for a single user session, but Application State is for all users and sessions. Application State does not have a default expiration period. When we close the worker process the application object will be lost. Technically the data is shared amongst users by a HTTPApplcationState class and the data can be stored here in a key/value pair. It can also be accessed using the application property of the HTTPContext class.

Application State Life Cycle

Step 1: When the Browser sends a request to the web server and the server receives the request it first checks the extension to determine whether or not it is ISAPI because this request can only be handled by the ISAPI extension; if the extension is different then the request is handled by the server itself.

Step 2: After receiving the request the Application Manager creates an application domain. In the application domain an instance of the class HostingEnvironment is created that provides access to information about all application resources.

Step 3: After creating the application domain, ASP.NET initializes the basic objects as HTTPContext, HTTPRequest and HTTPResponse. HTTPContext holds objects to the specific application request as HTTPRequest and HTTPResponse.HTTPRequest contains all the information regarding the current request like cookies, browser information and so on and the HTTPResponse contains the response that is sent to the client.

Step 4: Here all the basic objects are being initialized and the application is being started with the creation of the HTTPApplication class.

Step 5: Then events are executed by the HTTPApplication class for any specific requirement. Here is a list of events:

Global.asax file: the Global.asax file is used for handling application events or methods. It always exists in the root level. Events are one of the following of the 2 types in the Global application:

1. Events that will be raised on a certain condition.
2. Events that will be raised on every request.

The application will be started only once; if 10 users send a request then 10 user sessions are created. The events of the Global.asax file are:

1. Application_Start() : This method is invoked initially when first application domain is created.
2. Session_Start() : This method is called every time a session is start.
3. Application_BeginRequest() : After an application has started the first method Application_BeginRequest() is executed for every user.
4. Application_AuthenticateRequest() : It checks to determine whether or not the user is valid.
5. Application_Error() : Whenever an unhandled exception occurs then this event will be called.
6. Session_End() : When a user session is ended and all the data related to a specific user is cleared then the Session_End() event is called.
7. Application_End() : This method is called before the application ends. This can take place if IIS is restarted or the application domain is changing.
8. Application_Disposed() : This event is called after the application will be shut down and the .NET GC is about to reclaim the memory it occupies. Although this is very late to perform any clean-up but we can use it for safety purposes.

ASP.NET Application State real-life example

Step 7: Now to count the number of users online we need to use the global.asax file as in the following:

Step 8: Now to show the online users we need to use a web form as in the following:

Output

When the same request is sent to the server with a different browser then the number of online clients is also not increased because the browser binds with the session id so both of the tabs have the same session id so the server knows that the request comes from the same user. If we change the session id from the URL and again refresh then the number of online clients is increased by one because the server thinks that the request comes from a different browser.

Important points of Application State variables

1. Application State variables are available across all pages and all sessions. Application State variables are like multi-user Global data.
2. Application variables are stored on a web server.
3. Application State variables are cleared, only when the process hosting the application is restarted, that is when the application is ended.
4. Application State variables do not support web farms and web gardens: Application State variables are not supported be web farms.

   

   A client sends a request and the request goes to the load balancer and the load balancer sends a request to web server1 and the Application State variables are stored in a web server1. If the subsequent request is sent by the client again and the load balancer sends a request to web server2 and the Application State variables are not stored in web server2 then something. Web servers do not share application state variables.

5. Application State variables have a concurrency problem so we need to synchronize the method by using the lock and unlock methods. So multiple thread problems are resolved since only one thread can do the work.
6. An application variable is used only when the variable needs to have global access and when you need them for the entire time, during the lifetime of an application.