使用CallContext存储WCF的HttpContext

Question

我目前有一个WCF服务，用于执行一些数据库查询和发送邮件。长话短说，这两种方法都是异步在实现中使用HttpContext.Current的。

我最初的问题是，在第一个await之后，HttpContext.Current变为null，因此第二个操作失败。我在谷歌上搜索了几个小时，我测试了我发现的一切.自定义同步上下文中的appSettings在web.config中以.NET 4.5为目标，启用了ASP.NET兼容性，但没有工作。

然后，我发现这是如此的帖子在谈论CallContext。基本上，我们的想法是将HttpContext.Current存储在CallContext中。我做了测试，然后再尿尿，效果很好。然而，由于我不知道确切的CallContext是什么，我读到了它。

我不确定我是否真的正确地理解了一切，但是在我读完之后，我有一个担忧。我可能错了，但似乎无法保证异步调用完成后恢复的线程与初始线程相同。问题是，我在HttpContext中存储了几个值，而且我担心第一个方法使用用户A值执行，然后，一旦异步调用完成，第二个方法将使用用户B值执行(因为HttpContext将不是相同的)。

我想人们会很想告诉我，只将这些值存储在CallContext中，但是在遇到WCF问题之前，我创建了一个完整的体系结构，所以我不想完全回顾它，这就是为什么CallContext会派上用场，因为变化很小。

有人能告诉我我的理论是否正确吗？

Answer 1

WCF是某种程度上完整的SOA体系结构，支持多种协议&除了扩展之外，一切都是可配置的，您还可以扩展、定制所有东西。因此，获得一切都是非常tricky.Just的基础：

三种类型的WCF 并发是：

单：一个请求在给定的时刻可以访问WCF服务对象。

多重：在这个场景中，WCF服务对象可以在任何给定的时刻处理多个请求。

可重入：单个请求线程可以访问WCF服务对象，但是线程可以退出WCF服务来调用另一个WCF服务，也可以通过回调调用WCF客户端并在不死锁的情况下重新进入。

看起来很简单，但是等待它有实例模式，这与并发性不同。

-每个调用为每个客户端请求创建新的InstanceContext (因此也是服务对象)。

-每个会话为每个新的客户端会话创建新的InstanceContext (因此也是服务对象)，并在该会话的生存期内进行维护(这需要支持会话的绑定)。

-单实例：一个InstanceContext (因此是服务对象)在应用程序的生存期内处理所有客户端请求。

默认实例模式为每个会话，默认并发模式为单个

这意味着在更改WCF服务之前，您的服务只有一个实例上下文，允许每次在实例上下文中最多有一个线程处理消息。希望使用相同实例上下文的其他线程必须阻塞，直到原始线程退出实例上下文为止。

因此，在对此进行代码更改并希望其发生之前，您所担心的事情似乎是不可能的。

有关更多详细信息，请参阅：MSDN

Answer 2

您应该更改您的服务，以使它们不依赖于HttpContext.Current。最好完全不依赖HttpContext。

HttpContext.Current是相当于UI线程的服务器端。只是不要在不需要依赖它的代码上使用它。