The Question :
282 people think this question is useful
I just discovered that every request in an ASP.Net web application gets a Session lock at the beginning of a request, and then releases it at the end of the request!
In case the implications of this are lost on you, as it was for me at first, this basically means the following:
Anytime an ASP.Net webpage is taking a long time to load (maybe due to a slow database call or whatever), and the user decides they want to navigate to a different page because they are tired of waiting, THEY CAN’T! The ASP.Net session lock forces the new page request to wait until the original request has finished its painfully slow load. Arrrgh.
Anytime an UpdatePanel is loading slowly, and the user decides to navigate to a different page before the UpdatePanel has finished updating… THEY CAN’T! The ASP.net session lock forces the new page request to wait until the original request has finished its painfully slow load. Double Arrrgh!
So what are the options? So far I have come up with:
- Implement a Custom SessionStateDataStore, which ASP.Net supports. I haven’t found too many out there to copy, and it seems kind of high risk and easy to mess up.
- Keep track of all requests in progress, and if a request comes in from the same user, cancel the original request. Seems kind of extreme, but it would work (I think).
- Don’t use Session! When I need some kind of state for the user, I could just use Cache instead, and key items on the authenticated username, or some such thing. Again seems kind of extreme.
I really can’t believe that the ASP.Net Microsoft team would have left such a huge performance bottleneck in the framework at version 4.0! Am I missing something obvious? How hard would it be to use a ThreadSafe collection for the Session?
The Question Comments :
The Answer 1
202 people think this answer is useful
If your page does not modify any session variables, you can opt out of most of this lock.
<% @Page EnableSessionState="ReadOnly" %>
If your page does not read any session variables, you can opt out of this lock entirely, for that page.
<% @Page EnableSessionState="False" %>
If none of your pages use session variables, just turn off session state in the web.config.
<sessionState mode="Off" />
I’m curious, what do you think “a ThreadSafe collection” would do to become thread-safe, if it doesn’t use locks?
Edit: I should probably explain by what I mean by “opt out of most of this lock”. Any number of read-only-session or no-session pages can be processed for a given session at the same time without blocking each other. However, a read-write-session page can’t start processing until all read-only requests have completed, and while it is running it must have exclusive access to that user’s session in order to maintain consistency. Locking on individual values wouldn’t work, because what if one page changes a set of related values as a group? How would you ensure that other pages running at the same time would get a consistent view of the user’s session variables?
I would suggest that you try to minimize the modifying of session variables once they have been set, if possible. This would allow you to make the majority of your pages read-only-session pages, increasing the chance that multiple simultaneous requests from the same user would not block each other.
The Answer 2
84 people think this answer is useful
OK, so big Props to Joel Muller for all his input. My ultimate solution was to use the Custom SessionStateModule detailed at the end of this MSDN article:
- Very quick to implement (actually seemed easier than going the provider route)
- Used a lot of the standard ASP.Net session handling out of the box (via the SessionStateUtility class)
This has made a HUGE difference to the feeling of “snapiness” to our application. I still can’t believe the custom implementation of ASP.Net Session locks the session for the whole request. This adds such a huge amount of sluggishness to websites. Judging from the amount of online research I had to do (and conversations with several really experienced ASP.Net developers), a lot of people have experienced this issue, but very few people have ever got to the bottom of the cause. Maybe I will write a letter to Scott Gu…
I hope this helps a few people out there!
The Answer 3
31 people think this answer is useful
I started using the AngiesList.Redis.RedisSessionStateModule, which aside from using the (very fast) Redis server for storage (I’m using the windows port — though there is also an MSOpenTech port), it does absolutely no locking on the session.
In my opinion, if your application is structured in a reasonable way, this is not a problem. If you actually need locked, consistent data as part of the session, you should specifically implement a lock/concurrency check on your own.
MS deciding that every ASP.NET session should be locked by default just to handle poor application design is a bad decision, in my opinion. Especially because it seems like most developers didn’t/don’t even realize sessions were locked, let alone that apps apparently need to be structured so you can do read-only session state as much as possible (opt-out, where possible).
The Answer 4
21 people think this answer is useful
I prepared a library based on links posted in this thread. It uses the examples from MSDN and CodeProject. Thanks to James.
I also made modifications advised by Joel Mueller.
Code is here:
ScaleOut StateServer module:
If you want to implement support of Memcached or Redis, install this package. Then inherit the LockFreeSessionStateModule class and implement abstract methods.
The code is not tested on production yet. Also need to improve error handling. Exceptions are not caught in current implementation.
Some lock-free session providers using Redis:
The Answer 5
13 people think this answer is useful
If you are using the updated
3.0.2) you can add this to your
web.config to allow concurrent sessions.
<add key="aspnet:AllowConcurrentRequestsPerSession" value="true"/>
The Answer 6
11 people think this answer is useful
Unless your application has specially needs, I think you have 2 approaches:
- Do not use session at all
- Use session as is and perform fine tuning as joel mentioned.
Session is not only thread-safe but also state-safe, in a way that you know that until the current request is completed, every session variable wont change from another active request. In order for this to happen you must ensure that session WILL BE LOCKED until the current request have completed.
You can create a session like behavior by many ways, but if it does not lock the current session, it wont be ‘session’.
For the specific problems you mentioned I think you should check HttpContext.Current.Response.IsClientConnected. This can be useful to to prevent unnecessary executions and waits on the client, although it cannot solve this problem entirely, as this can be used only by a pooling way and not async.
The Answer 7
6 people think this answer is useful
For ASPNET MVC, we did the following:
- By default, set
SessionStateBehavior.ReadOnly on all controller’s action by overriding
- On controller actions that need writing to session state, mark with attribute to set it to
Create custom ControllerFactory and override
protected override SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, Type controllerType)
var DefaultSessionStateBehaviour = SessionStateBehaviour.ReadOnly;
if (controllerType == null)
var isRequireSessionWrite =
controllerType.GetCustomAttributes<AcquireSessionLock>(inherit: true).FirstOrDefault() != null;
var actionName = requestContext.RouteData.Values["action"].ToString();
actionMethodInfo = controllerType.GetMethod(actionName, BindingFlags.IgnoreCase | BindingFlags.Public | BindingFlags.Instance);
var httpRequestTypeAttr = GetHttpRequestTypeAttr(requestContext.HttpContext.Request.HttpMethod);
mi => mi.Name.Equals(actionName, StringComparison.CurrentCultureIgnoreCase) && mi.GetCustomAttributes(httpRequestTypeAttr, false).Length > 0);
if (actionMethodInfo == null)
isRequireSessionWrite = actionMethodInfo.GetCustomAttributes<AcquireSessionLock>(inherit: false).FirstOrDefault() != null;
return isRequireSessionWrite ? SessionStateBehavior.Required : DefaultSessionStateBehaviour;
private static Type GetHttpRequestTypeAttr(string httpMethod)
throw new NotSupportedException("unable to determine http method");
public sealed class AcquireSessionLock : Attribute
Hook up the created controller factory in
Now, we can have both
read-write session state in a single
public class TestController : Controller
public ActionResult WriteSession()
var timeNow = DateTimeOffset.UtcNow.ToString();
Session["key"] = timeNow;
return Json(timeNow, JsonRequestBehavior.AllowGet);
public ActionResult ReadSession()
var timeNow = Session["key"];
return Json(timeNow ?? "empty", JsonRequestBehavior.AllowGet);
Note: ASPNET session state can still be written to even in readonly
mode and will not throw any form of exception (It just doesn’t lock to
guarantee consistency) so we have to be careful to mark
AcquireSessionLock in controller’s actions that require writing session state.
The Answer 8
4 people think this answer is useful
Marking a controller’s session state as readonly or disabled will solve the problem.
You can decorate a controller with the following attribute to mark it read-only:
the System.Web.SessionState.SessionStateBehavior enum has the following values:
The Answer 9
0 people think this answer is useful
Just to help anyone with this problem (locking requests when executing another one from the same session)…
Today I started to solve this issue and, after some hours of research, I solved it by removing the
Session_Start method (even if empty) from the Global.asax file.
This works in all projects I’ve tested.
The Answer 10
0 people think this answer is useful
After struggling with all available options, I ended up writing a JWT token based SessionStore provider (the session travels inside a cookie, and no backend storage is needed).
- Drop-in replacement, no changes to your code are needed
- Scale better
than any other centralized store, as no session storage backend is
- Faster than any other session storage, as no data needs to be
retrieved from any session storage
- Consumes no server resources for
- Default non-blocking implementation: concurrent
request won’t block each other and hold a lock on the session
- Horizontally scale your application: because the session data travels
with the request itself you can have multiple web heads without
worrying about session sharing.