关于异步操作后的 c#:HttpContext.Current.Items


HttpContext.Current.Items after an Async operation

考虑以下 ASP.NET Web API 委托处理程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class MyHandler : DelegatingHandler
{
    protected async override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
    {
        var guid = Guid.NewGuid();
        HttpContext.Current.Items["foo"] = guid;

        // An Async operation
        var result = await base.SendAsync(request, cancellationToken);

        //All code from this point is not gauranteed to run on the same thread that started the handler

        var restoredGuid = (Guid)HttpContext.Current.Items["foo"];

        //Is this gauranteed to be true
        var areTheSame = guid == restoredGuid;

        return result;
    }
}

上面的例子是在一个委托处理程序中，我试图解决的同样的问题也适用于控制器、业务对象等。

我最终试图在每个 HTTP 请求的各种对象之间提供一些简单的内存共享状态

据我了解，在异步操作期间，最初运行该操作的 ASP.NET 线程将返回到线程池，并且在异步操作完成后，可能会使用不同的线程来完成请求。

这会影响 HttpContext.Current.Items 集合吗？
Items 集合中的项目是否保证在请求恢复时存在？

  • 我知道使用 HttpContext.Current 经常被
    由于我完全同意的原因，这些天来更广泛的社区
    与...我只是在帮助某人摆脱困境。

  • 将此数据存储在 Request.Items 集合中不适合解决此问题，因为我的同事由于一些糟糕的设计决策而需要静态。

    • 非常感谢

    相关讨论

    As I understand it during Async operations the ASP.NET thread originally running the operation is returned to the thread pool and a different thread may be used to finish the request after the Async operation has completed.

    没错。但是让我们花一分钟时间来谈谈 ASP.NET 上的 async。

    async 需要 .NET 4.5。此外，ASP.NET 4.5 在服务器端引入了"怪癖模式"，您必须关闭 SynchronizationContext 怪癖。您可以通过将 httpRuntime.targetFramework 设置为 4.5 或使用 aspnet:UseTaskFriendlySynchronizationContext 值为 true.

    的 appSettings 来执行此操作

    如果您的 web.config 没有这些条目之一，则 async 的行为未定义。有关更多详细信息，请参阅此帖子。我建议使用 targetFramework 设置并修复出现的任何问题。

    Does this affect the HttpContext.Current.Items collection? Is an item that was in the Items collection guaranteed to be there when the Request resumes?

    AspNetSynchronizationContext 跨 await 点保留当前请求上下文。这包括 HttpContext.Current(其中包括 Items、User 等)。

    另一种可能是CallContext.Logical[Get|Set]Data，它也流过await点。如果您不希望代码依赖于 HttpContext，这很有用，但开销会稍大。

    几周前，我在服务器端的 async 的 ThatConference 上做了一次演讲；您可能会发现这些幻灯片很有帮助，尤其是那些处理上下文和线程本地状态的幻灯片。

    相关讨论

    长话短说，通常应该如此。除非您使用的是 ConfigureAwait(false) ，否则它可能会产生副作用，继续不流动上下文。

    或者尝试在您的应用中添加此设置。

    1
    </appSettings>

    更新

    注意！！
    最初我把假的。但它必须是真实的，这样上下文才能流动。