Reputation: 877
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)
Upvotes: 3
Views: 2570
Reputation: 42363
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.
Upvotes: 2