Sessions in Asynchronous design
Asked Answered
P

2

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.

Phillipphillipe answered 25/2, 2011 at 14:14 Comment(5)
maybe helpful #2716032Carlacarlee
There was a question a day or two ago about session locking in PageMethods though I can't find it now. I think the upshot was don't use PageMethods, use a WebService.Wholesome
My understanding is that the session is not available to a webservice as well, is that true?Phillipphillipe
If you implement System.Web.SessionState.IRequiresSessionState (a marker interface) it is.Wholesome
System.Web.SessionState.IRequiresSessionState still locks the multiple asyn calls. IReadOnlySessionState does not write, thus not holding a lock on SessionPhillipphillipe
P
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

Phillipphillipe answered 2/3, 2011 at 21:7 Comment(1)
+1 Nice summary for dealing with a problem that seems to come up more and more.Wholesome
A
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.

Anjaanjali answered 25/2, 2011 at 19:24 Comment(4)
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.Wholesome
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.Anjaanjali
@jamietre How did you access session state in asynchronous calls? Can you take a look at my question? #11488305Oxidation
@Broken Link - To access session from an async call like a page method use HttpContext.Current.SessionSweetheart

© 2022 - 2024 — McMap. All rights reserved.