Ich dachte immer, dass das Setzen von InstanceContextMode auf PerCall den Parallelitätsmodus irrelevant macht, selbst wenn eine sitzungsbewusste Bindung wie net.tcp verwendet wird. Das sagt MSDNhttp://msdn.microsoft.com/en-us/library/ms731193.aspx "In PerCallinstancing ist Parallelität nicht relevant, da jede Nachricht von einem neuen InstanceContext verarbeitet wird und daher nie mehr als ein Thread im InstanceContext aktiv ist."

Aber heute habe ich Juval Lowys Buch Programming WCF Services durchgesehen und er schreibt in Kapitel 8

Wenn der Service pro Anruf eine Sitzung auf Transportebene hat, ist es ein Produkt des Service-Nebenläufigkeitsmodus, ob die gleichzeitige Verarbeitung von Anrufen zulässig ist. Wenn der Dienst mit ConcurrencyMode.Single konfiguriert ist, ist die gleichzeitige Verarbeitung anstehender Anrufe nicht zulässig, und die Anrufe werden einzeln weitergeleitet. [...] Ich halte dies für ein fehlerhaftes Design. Wenn der Dienst mit ConcurrencyMode.Multiple konfiguriert ist, ist die gleichzeitige Verarbeitung zulässig. Anrufe werden bei ihrem Eintreffen an eine neue Instanz weitergeleitet und gleichzeitig ausgeführt. Eine interessante Beobachtung ist, dass es im Interesse des Durchsatzes eine gute Idee ist, einen Per-Call-Service mit ConcurrencyMode.Multiple zu konfigurieren - die Instanz selbst ist immer noch thread-sicher (so dass Sie nicht für die Synchronisation verantwortlich sind). Sie können jedoch gleichzeitige Anrufe von demselben Client zulassen.

Dies widerspricht meinem Verständnis und den Aussagen von MSDN. Welches ist richtig ? In meinem Fall habe ich einen WCF Net.Tcp-Dienst verwendet, der viele Client-Anwendungen erstellt, ein neues Proxy-Objekt aufruft und den Proxy dann sofort schließt. Der Dienst verfügt über PerCall InstanceContextMode. Erhalte ich einen verbesserten Durchsatz, wenn ich den InstanceContextMode in Multiple ändere und kein schlechteres Thread-Sicherheitsverhalten als percall habe?