CODEWITHSUNDEEP
asp.netsessionconcurrency
Nick Bolton
Nick Bolton

Reputation: 39550

Is it possible to force request concurrency when using ASP.NET sessions?

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.

Upvotes: 10

Views: 2752

Answers (3)

Smartik.NET
Smartik.NET

Reputation: 136

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

Upvotes: 1

eglasius
eglasius

Reputation: 36037

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.

Upvotes: 3

LukeH
LukeH

Reputation: 269368

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

Upvotes: 1

Related Questions