Sitzungen, Instanziierung und Parallelität

Eine Sitzung ist eine Korrelation aller Nachrichten, die zwischen zwei Endpunkten gesendet werden. Instancing bezieht sich auf die Steuerung der Lebensdauer von benutzerdefinierten Dienstobjekten und ihren zugehörigen Objekten. Parallelität bezeichnet die Kontrolle der Anzahl von Threads, die gleichzeitig in einem InstanceContext ausgeführt werden.

In diesem Thema werden diese Einstellungen, deren Verwendung und die verschiedenen Interaktionen zwischen ihnen beschrieben.

Sitzungen

Wenn ein Dienstvertrag die ServiceContractAttribute.SessionMode Eigenschaft auf " SessionMode.Required" festlegt, sagt dieser Vertrag, dass alle Anrufe (d. h. der zugrunde liegende Nachrichtenaustausch, der die Anrufe unterstützt) Teil derselben Unterhaltung sein muss. Wenn ein Vertrag angibt, dass er Sitzungen zulässt, aber keines erfordert, können Clients eine Verbindung herstellen und entweder eine Sitzung herstellen oder nicht. Wird eine Sitzung beendet und eine Nachricht über diesen sitzungsbasierten Kanal gesendet, wird eine Ausnahme ausgelöst.

WCF-Sitzungen weisen die folgenden hauptkonzeptuellen Features auf:

Sie werden explizit von der aufrufenden Anwendung initiiert und beendet.
Während einer Sitzung übermittelte Nachrichten werden in der Reihenfolge verarbeitet, in der sie empfangen werden.
Sitzungen verknüpfen eine Gruppe von Nachrichten zu einer Unterhaltung. Die Bedeutung dieser Korrelation ist eine Abstraktion. So werden zum Beispiel bei einem sitzungsbasierten Kanal Nachrichten auf Grundlage einer gemeinsamen Netzwerkverbindung zueinander in Beziehung gesetzt, bei einem anderen Kanal geschieht dies wiederum auf Grundlage eines gemeinsamen Tags im Nachrichtentext. Die Features, die von der Sitzung abgeleitet werden können, hängen von der Art der Korrelation ab.
Es gibt keinen allgemeinen Datenspeicher, der einer WCF-Sitzung zugeordnet ist.

Wenn Sie mit der Klasse in ASP.NET Anwendungen und der darin bereitgestellten Funktionalität vertraut sind, stellen Sie möglicherweise die folgenden Unterschiede zwischen dieser Art von Sitzung und WCF-Sitzungen fest:If you are familiar with the System.Web.SessionState.HttpSessionState class in ASP.NET applications and the functionality it provides, you might notice the following differences between that kind of session and WCF sessions:

ASP.NET Sitzungen werden immer vom Server initiiert.
ASP.NET Sitzungen sind implizit ungeordnet.
ASP.NET-Sitzungen stellen einen allgemeinen Datenspeichermechanismus für Anforderungen bereit.

Clientanwendungen und Dienstanwendungen interagieren auf unterschiedliche Weise mit Sitzungen. Clientanwendungen initiieren Sitzungen und empfangen und verarbeiten dann die in der Sitzung gesendeten Nachrichten. Dienstanwendungen können Sitzungen als Erweiterungspunkt verwenden, um zusätzliches Verhalten hinzuzufügen. Dies erfolgt durch direktes Arbeiten mit dem InstanceContext oder der Implementierung eines benutzerdefinierten Instanzkontextanbieters.

Instanziierung

Das Instanzierungsverhalten (festgelegt mithilfe der Eigenschaft ServiceBehaviorAttribute.InstanceContextMode) steuert, wie das InstanceContext als Reaktion auf eingehende Nachrichten erstellt wird. Standardmäßig ist jedes InstanceContext objekt einem benutzerdefinierten Dienstobjekt zugeordnet, sodass (im Standardfall) die Einstellung der InstanceContextMode Eigenschaft auch die Instancing von benutzerdefinierten Dienstobjekten steuert. Die InstanceContextMode Aufzählung definiert die Instanzierungsmodi.

Die folgenden Instanzierungsmodi sind verfügbar:

PerCall: Für jede Clientanforderung wird ein neues InstanceContext (und daher dienstobjekt) erstellt.
PerSession: Für jede neue Clientsitzung wird ein neues InstanceContext (und daher Dienstobjekt) erstellt und für die Lebensdauer dieser Sitzung verwaltet (dies erfordert eine Bindung, die Sitzungen unterstützt).
Single: Ein einzelnes InstanceContext (und daher Dienstobjekt) verarbeitet alle Clientanforderungen für die Lebensdauer der Anwendung.

Das folgende Codebeispiel zeigt den Standardwert InstanceContextMode , PerSession der explizit für eine Dienstklasse festgelegt wird.

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)]
public class CalculatorService : ICalculatorInstance
{
    ...  
}

Und während die ServiceBehaviorAttribute.InstanceContextMode-Eigenschaft steuert, wie häufig die InstanceContext freigegeben wird, steuern die Eigenschaften OperationBehaviorAttribute.ReleaseInstanceMode und ServiceBehaviorAttribute.ReleaseServiceInstanceOnTransactionComplete, wann das Serviceobjekt freigegeben wird.

Well-Known Singleton Services

Eine Variation von Einzelnen Instanzdienstobjekten ist manchmal nützlich: Sie können ein Dienstobjekt selbst erstellen und den Diensthost mithilfe dieses Objekts erstellen. Dazu müssen Sie auch die Eigenschaft ServiceBehaviorAttribute.InstanceContextMode auf Single festlegen, ansonsten wird eine Ausnahme ausgelöst, wenn der Diensthost geöffnet wird.

Verwenden Sie den ServiceHost(Object, Uri[]) Konstruktor, um einen solchen Dienst zu erstellen. Dieser stellt eine Alternative zur Implementierung eines benutzerdefinierten System.ServiceModel.Dispatcher.IInstanceContextInitializer dar, wenn Sie eine bestimmte Objektinstanz für einen Singleton-Dienst bereitstellen möchten. Sie können diese Überladung verwenden, wenn ihr Dienstimplementierungstyp schwer zu konstruieren ist (z. B. wenn er keinen parameterlosen öffentlichen Konstruktor implementiert).

Beachten Sie, dass, wenn ein Objekt an diesen Konstruktor übergeben wird, einige Features in Bezug auf das Instanzierungsverhalten der Windows Communication Foundation (WCF) anders funktionieren. Beispielsweise hat der Aufruf InstanceContext.ReleaseServiceInstance keine Auswirkung, wenn eine Singleton-Objektinstanz bereitgestellt wird. Ebenso wird jeder andere Instanz-Freigabemechanismus ignoriert. Das ServiceHost verhält sich immer so, als ob die Eigenschaft OperationBehaviorAttribute.ReleaseInstanceMode auf ReleaseInstanceMode.None für alle Vorgänge gesetzt ist.

Sie können auch steuern, welcher sitzungsbasierte Kanal oder Aufruf dem InstanceContext -Objekt zugeordnet wird, indem Sie diese Zuordnung selbst vornehmen.

Konkurrenz

Bei der Parallelität handelt es sich um die Steuerung der Anzahl von Threads, die gleichzeitig in einem InstanceContext aktiv sind. Dies wird durch die Verwendung von ServiceBehaviorAttribute.ConcurrencyMode zusammen mit der ConcurrencyMode-Aufzählung gesteuert.

Es stehen die folgenden drei Parallelitätsmodi zur Verfügung:

Single: In jedem Instanzkontext ist maximal ein Thread zur Nachrichtenverarbeitung gleichzeitig zulässig. Andere Threads, die denselben Instanzkontext verwenden möchten, müssen blockiert werden, bis der ursprüngliche Thread den Instanzkontext verlässt.
Multiple: Jede Dienstinstanz kann mehrere Threads haben, die Nachrichten gleichzeitig verarbeiten. Die Dienstimplementierung muss threadsicher sein, um diesen Parallelitätsmodus zu verwenden.
Reentrant: Jede Dienstinstanz verarbeitet jeweils nur eine Nachricht, akzeptiert jedoch eintrittsinvariante Aufrufe. Der Dienst akzeptiert diese Aufrufe nur, wenn er über ein WCF-Clientobjekt aufgerufen wird.

Hinweis

Das Verständnis und die Entwicklung von Code, der sicher mehr als einen Thread verwendet, können eine Herausforderung darstellen, um ihn erfolgreich zu schreiben. Stellen Sie vor der Verwendung Multiple oder Reentrant der Werte sicher, dass Ihr Dienst für diese Modi ordnungsgemäß konzipiert ist. Weitere Informationen finden Sie unter ConcurrencyMode.

Die Parallelität steht mit dem Instanziierungsmodus in Beziehung. Bei der PerCall-Instanziierung ist die Parallelität nicht relevant, weil jede Nachricht von einem neuen InstanceContext verarbeitet wird und daher nie mehr als ein Thread im InstanceContext aktiv ist.

Das folgende Codebeispiel veranschaulicht das Festlegen der ConcurrencyMode Eigenschaft auf Multiple.

[ServiceBehavior(ConcurrencyMode=ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.Single)]
public class CalculatorService : ICalculatorConcurrency
{
    ...  
}

Sitzungen interagieren mit InstanceContext-Einstellungen

Sitzungen und InstanceContext interagieren je nach Kombination des Wertes der SessionMode Enumeration in einem Vertrag und der ServiceBehaviorAttribute.InstanceContextMode Eigenschaft der Dienstimplementierung, die die Zuordnung zwischen Kanälen und spezifischen Dienstobjekten steuert.

Die folgende Tabelle zeigt das Ergebnis eines eingehenden Kanals, der Sitzungen unterstützt oder nicht unterstützt, wenn ein Dienst die Werte der ServiceContractAttribute.SessionMode Eigenschaft und der ServiceBehaviorAttribute.InstanceContextMode Eigenschaft kombiniert.

InstanceContextMode-Wert	Required	Allowed	NotAllowed
PerCall	– Verhalten bei sitzungsbasiertem Kanal: Eine Sitzung und ein InstanceContext pro Aufruf. – Verhalten bei nicht sitzungsbasiertem Kanal: Eine Ausnahme wird ausgelöst.	– Verhalten bei sitzungsbasiertem Kanal: Eine Sitzung und ein InstanceContext pro Aufruf. – Verhalten bei nicht sitzungsbasiertem Kanal: Ein InstanceContext pro Aufruf.	– Verhalten bei sitzungsbasiertem Kanal: Eine Ausnahme wird ausgelöst. – Verhalten bei nicht sitzungsbasiertem Kanal: Ein InstanceContext pro Aufruf.
PerSession	– Verhalten bei sitzungsbasiertem Kanal: Eine Sitzung und ein InstanceContext pro Kanal. – Verhalten bei nicht sitzungsbasiertem Kanal: Eine Ausnahme wird ausgelöst.	– Verhalten bei sitzungsbasiertem Kanal: Eine Sitzung und ein InstanceContext pro Kanal. – Verhalten bei nicht sitzungsbasiertem Kanal: Ein InstanceContext pro Aufruf.	– Verhalten bei sitzungsbasiertem Kanal: Eine Ausnahme wird ausgelöst. – Verhalten bei nicht sitzungsbasiertem Kanal: Ein InstanceContext pro Aufruf.
Ledig	– Verhalten bei sitzungsbasiertem Kanal: Eine Sitzung und ein InstanceContext für alle Aufrufe. – Verhalten bei nicht sitzungsbasiertem Kanal: Eine Ausnahme wird ausgelöst.	– Verhalten bei sitzungsbasiertem Kanal: Eine Sitzung und ein InstanceContext für den erstellten oder vom Benutzer angegebenen Singleton. – Verhalten bei nicht sitzungsbasiertem Kanal: Ein InstanceContext für den erstellten oder vom Benutzer angegebenen Singleton.	– Verhalten bei sitzungsbasiertem Kanal: Eine Ausnahme wird ausgelöst. - Verhalten mit Kanal ohne Sitzung: Ein InstanceContext für jedes erstellte Singleton oder für das vom Benutzer angegebene Singleton.

Siehe auch

Last updated on 2025-06-20