3

I have searched high and low for this solution. Any insights will be highly appreciated.

The Situation: When there multiple PageMethod calls in a single page, each of the method call holds a lock on the Session object thus blocking. The PageMethod calls can be made asynchronous only with @Page directive is turned to False|ReadOnly

Findings: When the Page directive is default (read/write) but the session is not used anywhere on the page, the calls are not blocked. Any read or write in to the session at the page level blocks the pagemethod calls.

The Problem: Making EnableSessionState=ReadOnly at the @Page directive is very restrictive and don't want to take that route.

Can the pagemethod calls not block? and still access the session? (may be not write but just read)

Oleks
  • 31,955
  • 11
  • 77
  • 132
Narmatha Balasundaram
  • 867
  • 3
  • 11
  • 26
  • 1
    So, why use PageMethods? Why not just create WCF services to suit your needs? – John Saunders Feb 24 '11 at 20:39
  • My guess is that Session is not thread safe, so the PageMethods block as they are outside the normal request/response cycle- many PageMethods could be called at the same time from the page a user is viewing. Is it necessary to call your PageMethods so frequently? Could you alter the design? http://programminglife.wordpress.com/2009/05/18/how-to-do-parallel-work-with-pagemethods/ Seems to provide a work around by implementing the async pattern. The comment at the bottom of the page even says that sessions will not be locked if you remove the Session_Start/Session_End handlers from Global.asax. – WiseGuyEh Feb 25 '11 at 00:10
  • @WiseGuyEh: The link above ensures that the PageMethod calls are truly parallel and the Session is available to the page(so not to have the @Page EnableSessionState set to ReadOnly) - But the BeginInvoke creates a new thread and that thread is not session aware as it is not a part of the page cycle. – Narmatha Balasundaram Feb 25 '11 at 18:40

2 Answers2

2

I don't believe you can do this without implementing your own session provider. There's some info on this MSDN page.

ASP.NET applications are inherently multithreaded. Because requests that arrive in parallel are processed on concurrent threads drawn from a thread pool, it's possible that two or more requests targeting the same session will execute at the same time. (The classic example is when a page contains two frames, each targeting a different ASPX in the same application, causing the browser to submit overlapping requests for the two pages.) To avoid data collisions and erratic behavior, the provider "locks" the session when it begins processing the first request, causing other requests targeting the same session to wait for the lock to come free.

Because there's no harm in allowing concurrent requests to perform overlapping reads, the lock is typically implemented as a reader/writer lock-that is, one that allows any number of threads to read a session but that prevents overlapping reads and writes as well as overlapping writes.

Danny Tuppeny
  • 40,147
  • 24
  • 151
  • 275
  • Yes, this is not possible with the ASP.NET session provider. And the ASP.NET session is locked when PageMethods are used (no ReadOnly option with PageMethods). I changed WebMethods into HttpHandler and used JQuery on the client side. I summarized the solution I used in http://stackoverflow.com/questions/5118236/sessions-in-asynchronous-design – Narmatha Balasundaram Mar 07 '11 at 14:17
0

Answer detailed in Sessions in Asynchronous design

Community
  • 1
  • 1
Narmatha Balasundaram
  • 867
  • 3
  • 11
  • 26