ASP.NET: How parallel requests are processed

Budda picture Budda · Oct 21, 2010 · Viewed 7k times · Source

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...

Answer

Aleksandar Mirilovic picture Aleksandar Mirilovic · Jan 26, 2012

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.