9

Let's imaging there are 2 pages on the web site: quick and slow. Requests to slow page are executed for a 1 minute, request to quick 5 seconds.

Whole my development career I thought that if 1st started request is slow: he will do a (synchronous) call to DB... wait answer... If during this time request to quick page will be done, this request will be processed while system is waiting for response from DB.

But today I've found: http://msdn.microsoft.com/en-us/library/system.web.httpapplication.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.

Does it mean that my original thoughts are wrong?

Could you please clarify what they mean? I am pretty sure that thing are as I expect...

Budda
  • 18,015
  • 33
  • 124
  • 206

3 Answers3

8

The requests have to be be processed in the sequential order on the server side if the both request use the same session state with read/write access, because of asp.net session locking.

You can find more information here: http://msdn.microsoft.com/en-us/library/ie/ms178581.aspx

Concurrent Requests and Session State

Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.) If the EnableSessionState value in the @ Page directive is set to ReadOnly, a request for the read-only session information does not result in an exclusive lock on the session data. However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.

Aleksandar Mirilovic
  • 1,298
  • 1
  • 11
  • 11
  • Any idea what happens with ASP.MVC actions that are marked with the `[AllowAnonymous]` attribute? Do they get serialized as well, when being generated by the same session, despite of the fact that you wont touch the session? – user2173353 Jun 22 '18 at 06:46
  • Anyone running on this problem could check this solution to keep request processing parallel and improve the performance: https://stackoverflow.com/a/50983771/2173353 – user2173353 Jun 22 '18 at 08:33
4

Your original thoughts are right, and so is the documentation. The IIS worker process can spawn many threads, each with their own instance of the HttpApplication class.

Klaus Byskov Pedersen
  • 117,245
  • 29
  • 183
  • 222
  • Apparently it also can despawn http://stackoverflow.com/questions/2675910/how-to-know-who-kills-my-threads – Justin Oct 21 '10 at 14:53
  • Do you want to say that it is possible to have SEVERAL instances of HttpApplication in any moment. It doesn't have a lot of sense for me... Am I correctly understand that only 1st created thread should generate "Application_Start" event? – Budda Oct 21 '10 at 16:17
  • The `HttpApplication` class is just a *CLASS*, I think you are thinking about it as something that it's not. I recommend you take a deeper look into the asp.net pipeline architecture. See here: http://msdn.microsoft.com/en-us/magazine/cc188942.aspx – Klaus Byskov Pedersen Oct 21 '10 at 16:29
  • 2
    Yes, it is possible to have several HttpApplications at any given moment. Each occupies a thread exclusively for the duration of a request. So, one HttpApplication per request, but it can be reused across requests. Let's say a request is in progress and IIS gets a new request. It will create a new HttpApplication instance in one of the webapp's AppDomains and serve the request using the new HttpApplication. Application_Start in global.asax is a funny thing. It actually only runs once per APPDOMAIN, not HttpApplication. One the other hand, things like HttpModules run once per HttpApplication. – Jeff Oct 21 '10 at 17:00
  • So I can put heavy (slow-loading) stateless resources whose concurrency I don’t want to deal with into `HttpApplication._ctor()` and `HttpApplication.Dispose()`. – binki Nov 27 '13 at 16:46
4

ASP .NET will host multiple AppDomains for your web application under a single worker process (w3wp.exe). It may even share AppDomains for different web applications under the same worker process (if they are assigned to the same app pool).

Each AppDomain that ASP .NET creates can host multiple HttpApplication instances which serve requests and walk through the ASP .NET lifecycle. Each HttpApplication can (as you've said) respond to one request at a time.

Jeff
  • 35,755
  • 15
  • 108
  • 220
  • 1
    Guess, you want to say "ASP .NET will host multiple AppDomains for your web applicationS". From my perspective it doesn't have any sense to have few app domains for one web application. Am I right? – Budda Oct 21 '10 at 16:15
  • 1
    From a multiple web application standpoint, it makes tons of sense. You definitely don't want two different web applications running in the same AppDomain and sharing resources from a security standpoint. In general, as I understand it, the purpose of running separate AppDomains within a single worker process is for stability, so a single AppDomain failure doesn't bring down the whole web app. – Jeff Oct 21 '10 at 16:51
  • "purpose of running separate AppDomains within a single worker process" is clear for me and I absolutely agree with that. But If I will spread my web application through few app domains, how can I use "singletons" in this case? I need to workaround a lot of things (single cache provider, etc)... but what this gives to me? – Budda Oct 21 '10 at 17:57
  • 1
    Yes, your singletons and caching will be specific to the AppDomain it's running in, UNLESS you use a shared session or cache server (out of proc). You run into these same issues of course if you have multiple front end servers that are load balanced. – Jeff Oct 21 '10 at 18:07
  • 1
    In other words, static values in an ASP .NET application is dangerous and should be avoided for the most part without careful consideration (this may be an overstatement, but just making a point). – Jeff Oct 21 '10 at 18:08
  • Jeff, thanks again. Agree, there are additional issues... But still, I don't see any value to have web application spread between few domains... Could you please be so kind to clarify? – Budda Oct 21 '10 at 18:21
  • Just found this: http://msdn.microsoft.com/en-us/library/7w2sway1.aspx. See maxAppDomains. – Jeff Oct 21 '10 at 18:55