WCF基础

      ServiceBehavior.ConcurrencyMode 用于控制具体服务对象的并发行为。有三种模型：
      。Single: 默认方式。服务实例是 single-threaded，不接受重入调用(reentrant calls)。也就是说对于同一个服务实例的多个调用必须排队，直到上一次调用完成后才能继续。 
      。Reentrant: 和 Single 一样，也是 single-threaded，但能接受重入调用，至于针对同一服务对象的多个调用依然需要排队。在 Single 模式下，当方法调用另外一个服务(Callback是客户端提供的服务)时，方法会阻塞，直到所调用的服务完成。如果方法不能重入，那么因无法接受所调用服务的返回消息(reply message)，无法解除阻塞状态而陷入死锁(deadlock)。Reentrant 模式就是为了解决 Single 的这种不足，允许方法重入以完成处理过程。 
      。Multiple: 和 Single、Reentrant 不同，Multiple 允许多个客户端同时调用服务方法。不再有锁的问题，同样也不再提供同步保障(synchronization guarantees)。使用此模式时，我们必须自行使用多线程同步机制(如使用 lock 关键字) 来保证数据成员的读写安全。
      使用方式如下：

    [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession,ConcurrencyMode=ConcurrencyMode.Single)]
    public class SessionModeService : ISessionModeAllowed
    {
        .......
    }

      我们可以看出，并发模型和实例模型（Instance Context Mode）是配合使用的。下面简要的分析:
      1、对实例模型为PerCall，任何并发模式都一样的效果，因为每次客户端的调用都是一个新的实例。
      2、对实例模型为PerSession，由于服务端会保存客户端的会话状态，如果并发模型为Single，通信方式为双向通信（Duplex），服务端无法接受重入调用,就会产生死锁。所以在实例模式为PerSession，通信方式为双向通信（Duplex）下不能选择并发模型为Single。
      3、对实例模型为Single，由于服务端有且仅有一个服务实例，通信方式为双向通信（Duplex），同样会产生死锁。