The nature of web applications is to respond to multiple requests in parallel. In ASP.NET worker process can host multiple AppDomains for the web application under a single worker process (w3wp.exe). It may even share AppDomains for different web applications under the same worker process. In the other hand Each AppDomain that ASP.NET creates can host multiple HttpApplication instances which serve requests and walk through the Asp.Net lifecycle And Each HttpApplication can respond to one request at a time.
Back there in our project we had an odd issue about long running requests which once a long running request was made, the user was not able to load any other pages in the web site. It was happening sometimes not all the times, this was the strange part. Eventually I came across to the following msdn article:
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.
As you may have noticed the problem shows up when an application uses ASP.NET Session to hold it’s user data.
So to solve the problem there are 2 main approaches:
- Do not using session at all
- Using session but with custom implementation of SessionStateModule with considering some locking/unlocking mechanisms
For the latter one there are samples you can find in the below references:
It’s worth mentioning that there are handy solutions to overcome the issue in some scenarios by using EnableSessionState in webform page directive or using SessionStateAttribute on ASP.NET MVC controllers.
Code samples:
ASP.NET Page directive
<%@ Page EnableSessionState="true|false|ReadOnly" %>ASP.NET MVC controller attribute
SessionState(SessionStateBehavior.ReadOnly)The Idea of locking the whole request in the default microsoft implementation of SessionStateModule is a poor application design, in my opinion. The amount of time I spent to come across the solution with considering a lot of ASP.NET experts which didn’t know about this behavior is a good reason.
By the way we simply decided to not use session at all in our application ;).
More references: