multithreading - WCF服务契约实现中的多线程操作

Question

我最近看到一个项目使用后台 worker 进行一些操作(从其他 Web 服务获取数据)并使用事件将数据扔给客户端。该项目是 WCF 服务，由另一个类库作为 WCF 客户端角色由 ASP.NET 网站使用，并依次向应用程序抛出事件。这个全多线程系列让我好奇地研究。我看到这是一个 basicHttpBinding绑定(bind)，服务的唯一行为是 UseSynchronizationContext=false我发现他们在无法解释的异常之后添加了它，这是正常的:)

现在我问的是默认 ConcurrencyMode对于basicHttpBinding .他们不应该成功吗Reentrant或者这是默认行为？

如果 WCF 服务从客户端关闭，这种情况是否会继续失败，因为他们已经有一个未设置到对象实例的无法解释的引用？
我相信在依赖 IIS 处理的 ASP.NET 项目消耗的 WCF 服务中使用多线程操作是不好的，因为在 WCF 服务将数据返回到客户端类库并将这些数据附加到页面之前，页面可能被发送到客户端。
你能讨论以上问题并解释你的想法吗？

当您需要这种异步编程风格来通知 WCF 消费者在长时间操作后使用 CallbackContracts 进行通知时，应该不会更好和嵌入式 WCF 技术，而不是多线程操作？

需要澄清以纠正设计并证明这是一个糟糕的服务架构，如果它是真的，我怀疑!

谢谢你。

Answer 1

它本质上并不是糟糕的架构，但听起来它确实造成了许多可能的陷阱。

WCF 客户端库将所有协调工作留给 ASP.NET 应用程序。如果 ASP.NET 应用程序未检查对 WCF 服务的调用是否已完成，则它可能会在使用服务中的值设置变量之前使用变量，以及其他此类竞争条件，除非明确设置某种协调方式针对完成事件的初始调用。

我的建议是重写 WCF 客户端异步方法以返回 Task对象，来自 System.Threading.Tasks命名空间(MSDN reference)。通过这种方式，您可以分离调用 WCF 服务的后台处理，并使用 Result Task 的属性(property)以确保服务已完成。

一个例子:

protected void Page_Load(object sender, EventArgs e)
{
    Task<string> t = Task<string>.Factory.StartNew(() =>
    {
        return MyWcfClientClass.StaticAsyncMethod(MyArguments);
    }

    /* other control initialization stuff here, while the task 
       and WCF call continue processing in background */

    /* Calling Result causes the thread to wait for the task to 
       complete as necessary, to ensure we have our correct value */
    MyLabel1.Text = t.Result;
}