10

We are building a AJAX enabled web application that makes multiple asynchronous requests to the server. Each of these server requests are long running server tasks with each returning back a JSON object to the html page. Each of these calls need read/write access to the Session object.

But the ASP.NET locks the session object when multiple asynchronous tasks are in process, thus blocking the first asynchronous call. So these asynchronous calls never happen in parallel.

PS: The asynchronous calls are PageMethod calls.

Are Sessions are 'not' recommended in the first place when used along-side asynchronous calls. Any other suggestions on designing this asynchronous request model will be highly appreciated.

Narmatha Balasundaram
  • 867
  • 3
  • 11
  • 26

2 Answers2

9

Thanks to everyone that posted answers and comments to my question. I'm summing up my findings and solution so that someone may find this useful.

Everyone that commented is correct about recommending not to use Sessions in asynchronous calls. So, how did I get around it?

  1. Changed PageMethod call into a HttpHandler implementing IReadOnlySessionState. (In my case, the Ajax call just needs 'read' access into the Session object)
  2. The Client-side JQuery makes the Ajax call to the server HTTPHandler
  3. The @Page EnableSessionState directive can be left to be default (Read/Write)

With the above solution, multiple async calls are possible with each call reading into the session object

For more information about making a Jquery call to a HTTP Handler returning a JSON object, here's the link

Narmatha Balasundaram
  • 867
  • 3
  • 11
  • 26
1

I would actually agree that sessions are not recommended when using asynchronous calls, in fact use of sessions should be minimal in any case. Most of my apps don't use sessionstate directly at all, except what's required by the Membership stuff internally.

Paul
  • 35,689
  • 11
  • 93
  • 122
  • 1
    Why are sessions not recommended for asynchronous calls? I use them all the time, though I'm not sure I've had a situation that required multiple async calls that needed session. But you need context for just about anything you do in a web app, unless it's just like getting a list of states or something. So you can either get context from session, or by passing an identifier to the service/method. The latter seems extraordinarily inefficient when you've already got the same info in the user's session, since presumably, you'd then have to look something up in a database to do anything. – Jamie Treworgy Feb 25 '11 at 19:44
  • Just in general, it's better to stay stateless where possible. If you're getting a list of states as you suggest, it's better to use Cache. session state just doesn't scale well, esp. – Paul Feb 25 '11 at 22:13
  • @jamietre How did you access session state in asynchronous calls? Can you take a look at my question? http://stackoverflow.com/questions/11487805/to-invoke-a-method-asynchronously-by-using-begininvoke-and-save-the-result-in-se – Broken Link Jul 16 '12 at 15:51
  • @Broken Link - To access session from an async call like a page method use HttpContext.Current.Session – Kenshin Jan 24 '13 at 04:50