10

ASP.NET does not allow concurrent requests for the same session; meaning that a user can only make 1 request at a time.

For example, say we have Test1.aspx:

  public partial class Test1 : System.Web.UI.Page
  {
    protected void Page_Load(object sender, EventArgs e)
    {
      Session["test"] = 1;
      System.Threading.Thread.Sleep(int.Parse(Request.QueryString["timeout"]));
    }
  }

... and Test2.aspx:

  public partial class Test2 : System.Web.UI.Page
  {
    protected void Page_Load(object sender, EventArgs e)
    {
      Session["test"] = 1;
      Label1.Text = DateTime.Now.ToString("dd/MM/yy HH:mm:ss");
    }
  }

When we visit Test1.aspx?timeout=10000, and then immediately after visit Page2.aspx, the 2nd request will have to wait for 10 seconds until the first request has finished.

I just learnt this today, and I've been using ASP.NET for 5 years! I didn't really believe it until I read it at the bottom of an MSDN page (ASP.NET Session State Overview).

So, is there a way to force concurrency? That is, other than making pages faster, or moving long running code to a background thread. I'm aware that you can make the session read only, but I'm not entirely sure this is a practical option.

Nick Bolton
  • 38,276
  • 70
  • 174
  • 242
  • wow, I've been using it since 1.0 and also didn't know that :( It's been a non issue in any of the apps I've worked with, but I wonder what that'd do in an app that uses the session for something and then proceeds to send a large download file to the browser. In fact, just had a flash back of me disabling session in a file handler, as we were planning to move the session off process in the future, I wonder how large the headache would have been to find out why the download blocked the app ... – eglasius Sep 13 '10 at 18:31
  • Upvote since this question has been in the back of my mind awhile too. Very closely related: does this concurrency restriction also apply to ASMX webservice calls where [WebMethod(EnableSession = true)]? – mikemanne Sep 13 '10 at 20:50
  • In my tests so far it's even worse than nbolton describes; even if Test2 didn't access/change Session, it would still block until Test1 had finished. The only way I can work around this is to explicitly set EnableSessionState="False" as a Page directive on Test2. – Chris Sep 20 '12 at 00:27
  • See also: http://stackoverflow.com/questions/3666556/a-non-locking-in-process-asp-net-session-state-store and http://stackoverflow.com/questions/8989648/replacing-asp-nets-session-entirely – Chris Sep 20 '12 at 18:35

3 Answers3

3

Although I just learned this from the question, I'd make sure to check the Locking Session-Store Data section in Implementing a Session-State Store Provider, for more information on the why its done.

Based on the above, it really doesn't seem like a good idea to try to work around that mechanism.

Like you mentioned, keep the requests short and move long running code out of the request thread. Additionally:

  • disable the session if you don't need it. Most importantly do so if you are sending anything large in that request.
  • avoid unnecessary use of the session.

All of those are something you should already be doing anyway.

eglasius
  • 35,831
  • 5
  • 65
  • 110
  • If you want to try to implement a custom Session-State Provider to work around this, I found this MSDN article [Session State Providers](http://msdn.microsoft.com/en-us/library/aa478952.aspx) helpful, especially its clarification of when GetItem and GetItemExclusive are called. – Chris Sep 20 '12 at 18:28
1

For ASP.NET Pages you can try to change EnableSessionState value in the @ Page directive ReadOnly.

.NET Framework 4.5 added a new HttpContext.SetSessionStateBehavior method that can be used to set the Session behavior to the entire Application

Smartik.NET
  • 136
  • 1
  • 4
1

As far as I'm aware this isn't possible without creating your own session-state provider.

(If you're using SQL Server as your session store then it might be possible to hack the stored procedures to allow concurrent reads, but definitely not recommended.)

LukeH
  • 263,068
  • 57
  • 365
  • 409