3

I have the following scenario (Asp.net 3.5, Windows Server 2008 R2, IIS7):

  • User1 logs into abc.com using Firefox, and goes to a page that takes several minutes to load.
  • While that page is loading, User1 cannot load any other pages on the site.
  • All other page request on the site for User1 with this browser do not receive a response until the first page either finishes loading or times out (then the other requests are completed in quick succession).
  • While the first page is still loading (and other requests are on hold) if I open up a different browser (Chrome, though could just as easily be IE) and log on to the site with the same user, I have no problem loading page.

So it seems that the one individual user session is only able to handle a single request at a time (since the same user logging in with a different browser is really a different session to ASP.net).

What I would like to happen is that while the long-loading request for User1 is loading, that User1 is able to load other pages on the site (in the same browser).

Monitoring the server, there are no memory issues (none for Sql Server either). I am doing this while I am the only person using the site. Site is ASP.net 3.5, using Forms authentication. Only non-standard setup detail is that ViewState is being stored in Session.

In my searching so far, I have not been able to find anything relating to this. If this is the expected behavior, how can I override it? If this is not the expected behavior, what could be causing it, and how can I fix it?

Yaakov Ellis
  • 40,752
  • 27
  • 129
  • 174
  • First question -- what's happening on the server that takes several minutes to complete? Is this expected behavior? Will every user encounter this or is this happening as part of App_Start() or whatever it is called? – Bob Kaufman Oct 31 '10 at 12:11
  • It is a specific page that the user will go to. Normally is expected behavior, could very extremely long-running query (users can query tables containing millions of records). This has also happened because of unexpected behavior (bug in code causes response to take a long time). However, even in this case, it is only affecting this user/browser. – Yaakov Ellis Oct 31 '10 at 12:19
  • So its a long-winded report that, from a user's point of view, one would expect to take a long time. Can you consider running the report asynchronously -- that is, "click this link and we'll email this report shortly"? Then, you kick the report off in its own thread and nobody's inconvenienced. – Bob Kaufman Oct 31 '10 at 12:26
  • Bob - I have done this for a number of long-running processes, and plan on doing it more whenever I find processes that need it. The problem is that sometimes it is a process that doesn't lend itself to being asynchronous, and sometimes it is a bug that until fixed, can end up tying up a user for a while (whereas if the user's other page requests were answered, it wouldn't be so painful). Do you have any ideas about how to answer the question asked above? – Yaakov Ellis Oct 31 '10 at 12:37

1 Answers1

3

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

Yaakov Ellis
  • 40,752
  • 27
  • 129
  • 174
danielfishr
  • 879
  • 6
  • 9