Quote from MSDN about System.Web.HttpApplication

Question

Quote from http://msdn.microsoft.com/en-us/library/4wt3wttw.aspx:

One instance of the HttpApplication class is used to process many requests in its lifetime. However, it can process only one request at a time. Thus, member variables can be used to store per-request data.

Why per-request? Maybe per set of requests? Seems that member variables can be used to store data during full lifecycle of HttpApplication. Thus state of HttpApplication at the beginning of second (for this HttpApplication) request is equal to the state at the end of first (for this HttpApplication) request.

Why per-request?

Answer 1

A request whenever it comes to IIS is given to one of the HttpApplication instances (picked from the app. pool of a web app.). The events of this HttpApplication (defined in global.asax) will be available to the request.

From what I understand it'd create inconsistency if multiple requests could access an HttpApplication simulataneously. Asp.Net is in itself a very complex architecture, concurrency would make it a real nightmare to work with.

The per-request data thing is slightly twisted or I may not have gotten the concept right but I think it should mean that at one point in time the HttpApplication is dealing with only one request and not that it can hold variables/values put in the Application object by one request. Because any data put in the Application object is not per-request, rather it's available to all the requests.

Let me know whether this is what you're looking for :P

P.S. Here's the BEST link to understand Asp.Net (http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp)

Check the HttpApplication section to understand this better.

Answer 2

It's stating that the members of the HttpApplication object can be used to store per-request data. This doesn't mean that the members are restricted to per-request data. The HttpApplication.Application member holds the members that are global to the entire application, but during the processing of the request, the specific HttpApplication instance may only modify the global information kept in the ApplicationState object with the information in the request currently being processed. If the HttpApplication object had access to multiple requests simultaneously, conceivably it would be able to modify global data with aggregate or select data from any of the requests. As @Sidharth Panwar mentioned, this would create concurrency issues, and it would also be a nightmare to allow multiple requests to be processed because they would need to be guaranteed to come from the same user (for security/memory reasons) which can't be guaranteed since IIS queues up the next available HttpApplication object whenever a new request is made. It would lead to a single instance potentially handling a bulk of the load (and thus bottle-necking).