异步WCF REST服务中线程的上下文

我使用202 approach创建异步REST API。我必须在WCF（而不是Web API）中实现它，我的计划是产生一个新的线程来执行异步工作，同时让WCF操作线程返回202.我遇到的问题是一些遗留代码，需要在新线程中使用期望OperationContext和HttpContext来存储和检索上下文信息。我知道这些都是线程特定的，因此在产生的线程中是空的。异步WCF REST服务中线程的上下文

我有两个问题：

有没有的OperationContext和/或的HttpContext传播到新的线程任何安全的方式？
如果我能够修改传统的代码以从OperationContext和HttpContext移开，是否存在推荐的方式在WCF设置中的多个线程之间共享上下文信息？

来源

2014-01-07 BitMask777

你可以发布代码示例 –

您将负责确保您收到产卵必要的上下文的线程。 WCF只负责确保OperationContext流程与任何启动的线程切换，这就是推荐使用IExtension<OperationContext>来存储上下文数据的原因。一旦你离开大楼，你自己...
对于线程池上的产卵任务，典型的方法是准备任何必要的上下文信息，然后将其传递给委托，例如， Task.Run(() => doLongRunningTask(contextCopiedFromOperationContext))。在调用实际的长时间运行实现之前，代理将负责填充ThreadLocal<T>对象（或任何您想使用的机制）。

来源

2014-01-07 10:29:19

谢谢菲尔。与您对IExtension 的评论相关，我还将把我们遗留的代码使用HttpContext.Items转移到使用OperationContext扩展。管理OperationContext（比如OperationContextScope）的机制似乎比HttpContext好得多，另外它让我们远离了对ASP/System.Web的依赖。 – BitMask777

在服务器端OperationContext和HttpContext非常相似。使用你可以依赖你的状态在请求期间可用。使用HttpContext的好处是，如果您在同一台服务器上托管WCF和ASP.NET函数，则可以使用一致的机制。另一个可能的好处是HttpContext比OperationContext更长（它是先前创建的，稍后放置在管道中）。 –

异步WCF REST服务中线程的上下文

回答

相关问题