Problem

We are developing a MDI web application. On the left hand side is a tree control. On click of a node an iframe opens in right side. When user simultaneously clicks nodes as many iframes open and requests are sent using AJAX.

I have put a delay of 10 seconds on aspx page. The response from first request is received after 10 seconds and the second after 20 seconds and so on...

Possible Reasons

But the same problem occurs on the server side i.e if two simultaneous requests are sent to the same ASP.NET user session, it queues it for obvious reasons. The reason is that access to session state is serialised (http://odetocode.com/Blogs/scott/archive/2006/05/20/3648.aspx) i.e session state uses a Reader-Writer lock.

          Please find extract from http://www.eggheadcafe.com/articles/20021016.asp

         Session state implements a reader/writer locking mechanism:
             - A page (or frame) that has session state write access (e.g. <%@ Page EnableSessionState="True" %>) will hold a writer lock on the session until the request finishes.
             - A page (or frame) that has session state read access (e.g. <%@ Page EnableSessionState="ReadOnly" %>) will hold a reader lock on the session until the request finishes.
             - Reader lock will block a writer lock; Reader lock will NOT block reader lock; Writer lock will block all reader and writer lock.
             - That's why if two frames both have session state write access, one frame has to wait for the other to finish first.
       
    Solution : Simultaneous requests are allowed only if page does not access session state. One option for us is to make EnableSessionState to ReadOnly for all pages but this would not work for us because we write to session as well.

http://msdn2.microsoft.com/en-us/library/aa479034.aspx (Synchronizing Concurrent Accesses to a Session)

What are  options available ?

Hi sachinsurana

your problem is not obvious. Let me see if I got it.

You have your "details" page, which loads up when someone clicks a node in the tree. Somehow, this page takes 10secs to render. So, your problem is that you can't call it "concurrently", because of using the session and the resulting lock ?

First of all, if something needs to hold a lock on the session for 10 secs, then something's wrong with the way you do things. But, notwithstanding, I think you could benefit by making your pages asynchronous. In short, an async page will hold a thread until it hits it's "critical section" - the time-consuming work that needs to be done. Then that piece of code will execute on another thread, freeing up the original Page instance, to serve other users. When the critical section ends, the same page gets an event and returns to action to complete rendering.

Now, from what I understand, perhaps it'll take a bit more to completely eliminate your problem, but that will surely boost your performance no matter what. You can find a very good How-To from MSDN mag here.

Happy coding, hope this was helpful.

O:]

Hi anjelinio,

Thanks for your response. But the problem is a different one. Sorry for not articulating it well. To put it simply, say a page takes 10 seconds for processing (I have put an artificial delay of 10 seconds). Now I want to fire simultaneous request to the page in the same user session.

Its not our code that put lock on the session but it is ASP.NET that puts reader/writer lock on the session.

Hi anjelinio,

Thanks for your response. But the problem is a different one. Sorry for not articulating it well. To put it simply, say a page takes 10 seconds for processing (I have put an artificial delay of 10 seconds). Now I want to fire simultaneous request to the page in the same user session.

Its not our code that put lock on the session but it is ASP.NET that puts reader/writer lock on the session.

See what happens, here ... what I think locks you is not the session, but rather your own artificial delay ( Did you do a Thread.Sleep in there or something ? or is it some loop code ? ) that locks the Page instance you're calling. Async pages WILL solve your problem if you have some work to be done that takes a long time. An Async page will get freed-up to server other requests WHILE the time-consuming operation takes place.

Now, coming back to the Session lock, I find it  e x t r e m e l y  difficult that you can lock the Session instance for more than a few milliseconds, no matter what you do ! You see, the Session will get locked during "Add" or "Remove" or "Update" operations on it, but that will almost n e v e r take more a few milliseconds. You 'd have to use lock(){...} syntax to lock out the Session, and even then I have my doubts on whether you would actually manage to lock it ...

Weird, weird things you're describing my friend :D Take a closer look at your artificial delay code I say.