27

It seems to me that ASP.net queues up all requests that use the same Session ID. Let's say you've got 3 pages.

Default.aspx

protected void Page_Load(object sender, EventArgs e)
{
    Session["asdf"] = "LOLZ";
}

Hitting this page would obviously create a new session if one doesn't exist.

X-AspNet-Version: 2.0.50727
Set-Cookie: ASP.NET_SessionId=ibjphuv0aiafqi453tyze345; path=/; HttpOnly

Then you hit Hang.aspx

protected void Page_Load(object sender, EventArgs e)
{
    Thread.Sleep(10000);
}

And immediately after you hit any other page that this session ID would be passed to, doesn't matter if it does anything, let's call it Test.aspx.

The sequence for loading is like so.

Request            Timeline
"GET /"            |*|
"GET /Hang.aspx"       |******************************************|
"GET /Test.aspx"            |**************************************|

I guess my question is how do I disable this feature. I understand it's useful to have so that session state can be more predictable, however in my case a long running reports page load is killing users' ability to multitask.

Novikov
  • 4,399
  • 3
  • 28
  • 36

1 Answers1

25

This behaviour is by design; no concurrent access to the session state is allowed. Requests with same SessionID will be locked exclusively to prevent potential corruption of its state.

To get around this you can disable session state in your page directive.

<%@ Page EnableSessionState="false" %>

Read "Concurrent Requests and Session State" here http://msdn.microsoft.com/en-us/library/ms178581.aspx for more.

Setting EnableSessionState="ReadOnly" will prevent that page from gaining an exclusive lock on the SessionState (but the page itself would have to wait for other non-ReadOnly requests by the user to finish before loading).

(This is a copy and paste of my answer to this question ASP.net site: Long-loading page for user puts all other page loads for user on Hold)

Community
  • 1
  • 1
danielfishr
  • 879
  • 6
  • 9
  • 1
    Thank you for the link. Seems like a poor design decision on Microsoft's part since explicit locking or even locking items in the collection would remove this bizarre limitation. From some of my reading it seems this design is a holdover from when session data resided in a STAThread COM object. – Novikov Nov 30 '10 at 22:55
  • 3
    @Novikov: The problem is that session is loaded at the beginning and saved at end of every page request. Because of this it is basically volatile and not safe to be accessed by multiple pages during the cycle. Imagine if Hang.aspx changed a key session value that Test.aspx depended on? In this use case the app would be basically screwed. This isn't COM specific, but rather one of those unsolvable issues. – NotMe Nov 30 '10 at 23:11
  • 1
    +1 - I've never gotten around to reading as far as that last paragraph in the MS docs. – Kev Dec 01 '10 at 23:09
  • 2
    @kev they should definitely have put this in the first paragraph! it took me the best part of 10 years to find out about this feature. never even noticed it until those wierd things (bugs) happen in Fiddler that force you to delve deeper – Simon_Weaver Jun 21 '13 at 08:50
  • Is there a way to use something similar to EnableSessionState in a WCF-service hosted behind sharepoint? – Alex Dec 29 '20 at 14:27