Background
We all know that the web uses the HTTP protocol and that the HTTP protocol is a stateless protocol, in other words when a client sends a request to the server, an instance of the page is created and the page is converted to HTML format and then the server returns the response and then the instance of the page and the value of the control is destroyed. So if we have a requirement to store the value of controls then a State Management technique is used.
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:
- Events that will be raised on a certain condition.
- 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:
- Application_Start() : This method is invoked initially when first application domain is created.
- Session_Start() : This method is called every time a session is start.
- Application_BeginRequest() : After an application has started the first method Application_BeginRequest() is executed for every user.
- Application_AuthenticateRequest() : It checks to determine whether or not the user is valid.
- Application_Error() : Whenever an unhandled exception occurs then this event will be called.
- 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.
- Application_End() : This method is called before the application ends. This can take place if IIS is restarted or the application domain is changing.
- 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
Now I am explaining the real-life example. If you want to see the number of users online then we need to use Application State.
Step 1: Open Visual Studio 2010.
Step 2: Then click on "New Project" > "Web" > "ASP.NET Empty Web Application" .
Step 3: Now click on Solution Explorer.
Step 4: Now right-click on "Add" > "New Item" > "Web Form" and add the name of the web form.
Step 5: Now add the Global.asax file. Again go to Solution Explorer and "Add" > "New Item" > "Global Application Class".
Step 6: Now to configure the session we need to use the web.config file as in the following:
- <sessionState mode="InProc" timeout="20" cookieless="true"></sessionState>
Step 7: Now to count the number of users online we need to use the global.asax file as in the following:
- protected void Application_Start(object sender, EventArgs e)
- {
-
- Application["user"] = 0;
- }
- protected void Session_Start(object sender, EventArgs e)
- {
-
- Application.Lock();
- Application["user"] = (int) Application["user"]+1;
- Application.UnLock();
- }
- protected void Session_End(object sender, EventArgs e)
- {
-
- Application.Lock();
- Application["user"] = (int)Application["user"] - 1;
- Application.UnLock();
- }
Step 8: Now to show the online users we need to use a web form as in the following:
- protected void Page_Load(object sender, EventArgs e)
- {
- Response.Write("The num of users online=" + Application["user"].ToString());
- }
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
- Application State variables are available across all pages and all sessions. Application State variables are like multi-user Global data.
- Application variables are stored on a web server.
- Application State variables are cleared, only when the process hosting the application is restarted, that is when the application is ended.
- 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.
- 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.
- 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.