Siempre pensé que la configuración de InstanceContextMode en PerCall hace que el modo de concurrencia sea irrelevante incluso si se usa un enlace que tenga en cuenta la sesión como net.tcp. Esto es lo que dice MSDNhttp://msdn.microsoft.com/en-us/library/ms731193.aspx "En PerCallinstancing, la concurrencia no es relevante, porque cada mensaje es procesado por un nuevo InstanceContext y, por lo tanto, nunca más de un hilo está activo en el InstanceContext".

Pero hoy estaba revisando el libro de Juval Lowy, Programando los servicios de WCF, y él escribe en el Capítulo 8

Si el servicio por llamada tiene una sesión de nivel de transporte, si se permite el procesamiento simultáneo de llamadas es un producto del modo de concurrencia del servicio. Si el servicio se configura con ConcurrencyMode.Single, el procesamiento simultáneo de las llamadas pendientes no se permite y las llamadas se envían de una en una. [...] Considero que este es un diseño defectuoso. Si el servicio está configurado con ConcurrencyMode.Multiple, se permite el procesamiento simultáneo. Las llamadas se envían a medida que llegan, cada una a una nueva instancia, y se ejecutan simultáneamente. Una observación interesante aquí es que, en interés del rendimiento, es una buena idea configurar un servicio por llamada con ConcurrencyMode.Multiple: la instancia en sí misma será segura para subprocesos (por lo que no incurrirá en la responsabilidad de sincronización) , sin embargo, permitirá llamadas simultáneas desde el mismo cliente.

Esto contradice mi comprensión y lo que dice MSDN. Cual es correcta ? En mi caso, tengo un servicio WCF Net.Tcp que utiliza mis muchas aplicaciones cliente que crean un nuevo objeto proxy, realiza la llamada y luego cierra el proxy inmediatamente. El servicio tiene PerCall InstanceContextMode. ¿Obtendré un rendimiento mejorado si cambio el InstanceContextMode a Multiple sin un comportamiento de seguridad de subprocesos peor que percall?