WCF服务合同执行中的多线程操作

Question

我最近见过一个项目，使用后台工作人员进行一些操作（从其他Web服务获取数据），并使用事件将数据扔到客户端。此项目是一个WCF服务，由另一个类库作为WCF客户端角色由ASP.NET网站使用，并将轮流事件投掷到应用程序。这一切的多线程系列让我好奇的去检查。我已经看到了，这是一个basicHttpBinding绑定和服务的唯一行为是UseSynchronizationContext=false，我发现，他们增加了它无法解释的异常是正常的:)

现在，我问的是默认ConcurrencyMode为后basicHttpBinding。他们不应该让它Reentrant或这是默认行为？

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

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

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

谢谢。

Answer 1

这不是固有的坏架构，但它听起来像它确实造成了一些可能的陷阱。

WCF客户端库将所有协调留给ASP.NET应用程序。如果ASP.NET应用程序未检查对WCF服务的调用是否已完成，那么在使用变量设置服务中的值和其他此类竞争条件之前，除非明确设置某种协调方式，否则它有冒险使用变量的风险对完成事件的最初呼叫。

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

一个例子：

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; 
}