这个关于允许每个会话并发请求的答案很棒，但它缺少一些重要的细节:

控件中允许每个会话并发请求的设置 更新的ASP .NET会话状态模块 Microsoft.AspNet.SessionState.SessionStateModuleAsync。这个设置是 支持任何可以使用此模块的提供者。 年长的 sessionstate模块System.Web.SessionState.SessionStateModule 不支持这个。 确保会话状态的使用是线程安全的或 会话中可能出现并发问题

摘要以启用此功能:

允许并发请求:

<appSettings>
    <add key="aspnet:AllowConcurrentRequestsPerSession" value="true"/>
</appSettings>

确保使用更新的会话状态模块:

<system.webServer>
  <modules>
    <!-- remove the existing Session state module -->
    <remove name="Session" />
    <add name="Session" preCondition="integratedMode" type="Microsoft.AspNet.SessionState.SessionStateModuleAsync, Microsoft.AspNet.SessionState.SessionStateModule, Version=1.1.0.0, Culture=neutral" />
  </modules>
</system.webServer>

如果您正在使用更新的Microsoft.Web。RedisSessionStateProvider(从3.0.2开始)你可以将它添加到你的web中。配置允许并发会话。

<appSettings>
    <add key="aspnet:AllowConcurrentRequestsPerSession" value="true"/>
</appSettings>

源

我开始使用angieslist。redis。RedisSessionStateModule，除了使用(非常快)Redis服务器存储(我使用windows端口-尽管也有一个mopentech端口)，它绝对没有锁定会话。

在我看来，如果你的应用程序结构合理，这不是问题。如果您确实需要将锁定的、一致的数据作为会话的一部分，那么您应该自己专门实现锁/并发性检查。

微软决定每一个ASP。在我看来，为了处理糟糕的应用程序设计而默认锁定NET会话是一个糟糕的决定。特别是因为大多数开发人员似乎没有/甚至没有意识到会话被锁定，更不用说应用程序显然需要结构化，以便您可以尽可能地实现只读会话状态(在可能的情况下选择退出)。

对于ASPNET MVC，我们做了以下工作:

缺省情况下，设置SessionStateBehavior。通过重写DefaultControllerFactory对所有控制器的动作进行只读 在需要写入会话状态的控制器动作上，用属性标记将其设置为SessionStateBehavior。要求

创建自定义ControllerFactory并覆盖GetControllerSessionBehavior。

    protected override SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, Type controllerType)
    {
        var DefaultSessionStateBehaviour = SessionStateBehaviour.ReadOnly;

        if (controllerType == null)
            return DefaultSessionStateBehaviour;

        var isRequireSessionWrite =
            controllerType.GetCustomAttributes<AcquireSessionLock>(inherit: true).FirstOrDefault() != null;

        if (isRequireSessionWrite)
            return SessionStateBehavior.Required;

        var actionName = requestContext.RouteData.Values["action"].ToString();
        MethodInfo actionMethodInfo;

        try
        {
            actionMethodInfo = controllerType.GetMethod(actionName, BindingFlags.IgnoreCase | BindingFlags.Public | BindingFlags.Instance);
        }
        catch (AmbiguousMatchException)
        {
            var httpRequestTypeAttr = GetHttpRequestTypeAttr(requestContext.HttpContext.Request.HttpMethod);

            actionMethodInfo =
                controllerType.GetMethods().FirstOrDefault(
                    mi => mi.Name.Equals(actionName, StringComparison.CurrentCultureIgnoreCase) && mi.GetCustomAttributes(httpRequestTypeAttr, false).Length > 0);
        }

        if (actionMethodInfo == null)
            return DefaultSessionStateBehaviour;

        isRequireSessionWrite = actionMethodInfo.GetCustomAttributes<AcquireSessionLock>(inherit: false).FirstOrDefault() != null;

         return isRequireSessionWrite ? SessionStateBehavior.Required : DefaultSessionStateBehaviour;
    }

    private static Type GetHttpRequestTypeAttr(string httpMethod) 
    {
        switch (httpMethod)
        {
            case "GET":
                return typeof(HttpGetAttribute);
            case "POST":
                return typeof(HttpPostAttribute);
            case "PUT":
                return typeof(HttpPutAttribute);
            case "DELETE":
                return typeof(HttpDeleteAttribute);
            case "HEAD":
                return typeof(HttpHeadAttribute);
            case "PATCH":
                return typeof(HttpPatchAttribute);
            case "OPTIONS":
                return typeof(HttpOptionsAttribute);
        }

        throw new NotSupportedException("unable to determine http method");
    }

AcquireSessionLockAttribute

[AttributeUsage(AttributeTargets.Method)]
public sealed class AcquireSessionLock : Attribute
{ }

在global.asax.cs中连接创建的控制器工厂

ControllerBuilder.Current.SetControllerFactory(typeof(DefaultReadOnlySessionStateControllerFactory));

现在，我们可以在一个Controller中同时拥有只读和读写会话状态。

public class TestController : Controller 
{
    [AcquireSessionLock]
    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);
    }
}

注意:ASPNET会话状态即使在只读状态下仍然可以被写入 模式，不会抛出任何形式的异常(它只是不锁定 保证一致性)，所以我们必须小心地在控制器需要写入会话状态的动作中标记AcquireSessionLock。

好的，非常感谢Joel Muller的贡献。我的最终解决方案是使用自定义SessionStateModule在这篇MSDN文章的最后详细说明:

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstateutility.aspx

这是:

非常快地实现(实际上似乎比走提供者路线更容易) 使用了很多标准的ASP。开箱即用的网络会话处理(通过SessionStateUtility类)

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...

除非你的应用程序有特殊的需求，我认为你有两种方法:

根本不使用会话 就像joel提到的那样使用session并执行微调。

Session不仅是线程安全的，而且是状态安全的，在某种程度上，您知道在当前请求完成之前，每个会话变量都不会因为另一个活动请求而改变。为了做到这一点，你必须确保会话将被锁定，直到当前请求完成。

你可以用很多方法创建一个类似会话的行为，但如果它不锁定当前会话，它就不是“会话”。

对于你提到的具体问题，我认为你应该检查HttpContext.Current.Response.IsClientConnected。这对于防止客户端上不必要的执行和等待非常有用，尽管它不能完全解决这个问题，因为这只能通过池化方式使用，而不是异步方式。