Web applications are stateless by nature, which means that you don’t have a native way to handle state. Even though no native way exists to handle state as per the HTTP protocol, modern application frameworks (like ASP.NET) provide a lot of features in this area.
The typical ASP.NET application contains different state management techniques that are related to different scopes. Some data needs to be volatile but available for the entire request lifecycle, on a single-user basis; other kinds of information need to be available to all users.
We can split state handling into three main scenarios, depending on how we want to span the object’s lifetime.
Application State: The application state is used to store data on server. The data stored in the application state is available to all the users (sessions) accessing the application. The data in the application state is stored once and read several times. To access the data in the application state you must use the class HttpApplication. One disadvantage to application state classes is that they can cause deadlock where one user’s activity can unknowingly try to update a variable at the same time another user is also doing so, or cause race conditions and access violations. The HttpApplicationstate class provides a lock, method , which you can use to ensure that only one user is able to access and modify the data of an application at any instant of time.
Session State: Session state, in the context of .NET, is a method keep track of the a user session during a series of HTTP requests.Session state however is a Microsoft-centric concept. Session State stores the data specific to a user session in session variables. Different session variables are created for each user session. In addition, session variables can be accessed from any page of the application. When a user accesses a page , a session ID for the user is created. The session ID is transferred between the server and the client over the HTTP protocol using cookies. The biggest downside of session state is that state is maintained in the application pool of IIS on the web server. This isn’t an issue with one server, but it causes problems when scaling out to have multiple servers. The solution is to move to a state server, where session state is stored on a 3rd party server. Storing session state in the application pool also means that data is lost if the server is rebooted.
View State: View state stores page specific information , when a page is posted back to the server. When a page is processed, the current state of the page and its controls is hashed into a string and saved as a hidden field on the page. ViewState is both a joy and a pain for ASP.NET developers. You can use it to maintain the status across the different requests on a given page, but because it’s saved in a hidden field, it consumes bandwidth if it’s not used correctly.