IIS / .Net only allows single concurrent response to given user session

Question

Here is my problem:

We have a .Net 4.5 web forms application. Some pages in the application take a very long time to load due to heavy data access and manipulation on the server side. If a user closes their browser tab before the page completes loading, and opens a new tab, any requests to the application in the new tab will hang for 20 minutes or more, or just time out. However, if they open a new incognito window (Chrome) or another browser, they can connect immediately.

I believe this is because .Net handles concurrent requests from the same session sequentially, as explained here: ASP.NET Session State Overview

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.

Some posts I've found while researching this issue have alluded to (but not confirmed) that when the browser tab is closed before the response completes, the session gets "stuck" and will not respond to new requests from the same session until the set SessionTimeout period has elapsed. It is my hypothesis that a request from an incognito window is accepted because it has a new session.

Does anyone know of any way to free up the session to new requests, besides waiting for a timeout? Is there some way to detect that the client is no longer listening? I've found Response.IsClientConnected , which seems promising, but I am not sure how it would be used.

NOTE: This is a legacy application containing a significant amount of business logic, and current conditions do not allow the time or budget for a re-write at this time. Therefore, suggestions to "just re-write the pages so they load faster" aren't immediately feasible, though I acknowledge that would truly be the best solution.

Answer 1

Had a similar issue myself regarding concurrency and session state.

Try setting enableSessionState="ReadOnly" in your web.config.

See my thoughts here: EnableSessionState = ReadOnly - possible side effects?

Edit: sorry, saw that you might already have tried doing this.

Answer 2

Doing enableSessionState="Readonly" in web.config would improve your performance.

To allow session write, you can override this setting for a page as, <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="demo.aspx.cs" Inherits="com.Demo" EnableSessionState="true" %>

Requests for such pages would be served sequentially which makes sense as you are doing changes to session which you wouldn't want to be concurrent to avoid dirty reads.

Answer 3

Have you tried this session less mvc controller for mvc 2 rc ?

"You have a single client making multiple concurrent requests to the server. The default behavior is that these requests will be serialized; with the session less controller they execute in parallel. "

That link was old, but maybe you can find your solution following the Session less controller in MVC3 .