Fehlersemantik für Kontexthandles

In diesem Thema werden Fehlersemantiken für Kontexthandles erläutert.

Fehlersemantik beim Schließen des Kontexthandles schlägt fehl

Stellen Sie sich vor, eine Clientanwendung versucht, ein auf dem Server geöffnetes Kontexthandle zu schließen, ohne den Clientprozess herunterzufahren. Gehen Sie außerdem davon aus, dass der Aufruf des Servers zum Schließen des Kontexthandles fehlschlägt (z. B. ist der Client nicht genügend Arbeitsspeicher vorhanden). Die richtige Möglichkeit, diese Situation zu behandeln, besteht darin, die RpcSsDestroyClientContext-Funktion aufzurufen. In einem solchen Fall bereinigt der Client seine Seite des Kontexthandles und schließt die Verbindung mit dem Server abgebrochen. Da es sich bei der Verbindung tatsächlich um einen Verbindungspool handelt (siehe RPC und das Netzwerk), der mit einem Verweis für jeden geöffneten Bindungs- oder Kontexthandle mit einem Verweis gezählt wird, zerstört das Löschen des Kontexthandles durch Aufrufen der RpcSsDestroyClientContext-Funktion die Verbindung nicht. Stattdessen wird die Verweisanzahl für den Verbindungspool erhöht. Damit Verbindungen im Pool geschlossen werden können, muss der Client alle Bindungshandles und Kontexthandles für diesen Server aus dem Clientprozess schließen. Anschließend werden alle Verbindungen im Pool geschlossen, und der Serverausführungsmechanismus wird initiiert und bereinigt.

Fehlersemantik beim Ändern des Zustands des Kontexthandles

Die Informationen in diesem Abschnitt beziehen sich auf Windows XP und höhere Plattformen.

Kontexthandles sind einfach Parameter für eine Funktion. Alle Änderungen im Zustand eines Kontexthandles treten auf, wenn Parameter gemarst oder aufgehoben werden. Wenn ein Client beispielsweise ein Kontexthandle öffnet (es von NULL in non-NULL ändert), wird der RPC-Teil des Handles von der RPC-Laufzeit erst geöffnet, wenn die Argumente zum Senden an den Client gemarst werden. Während der Zwischenzeit können Fehler auftreten. Aufgrund einer Vielzahl möglicher Netzwerk- oder ressourcenarmer Bedingungen kann die Übertragung des Pakets an den Client fehlschlagen. Oder die Serverroutine löst eine Ausnahme aus, wenn versucht wird, ein Kontexthandle zu ändern. In diesen oder anderen Fehlersituationen erhalten Client und Server möglicherweise inkonsistente Ansichten des Kontexthandles. In diesem Abschnitt wird die Regel für den Status des Kontexthandles und die Verantwortung von Client- und Servercode während verschiedener Fehlerbedingungen erläutert.

• Ein NULL-Kontexthandle wird eingetroffen, aber die Serverroutine tritt auf einen Fehler und löst eine Ausnahme aus.

  Es liegt in der Verantwortung der Serverroutine, alle kontextbezogenen Zustände, die sie möglicherweise erstellt hat, zu sauber. Die RPC-Laufzeit bereinigt ihren Zustand.

• Es wird ein Nicht-NULL-Kontext behandelt, aber die Serverroutine tritt auf einen Fehler und löst eine Ausnahme aus.

  Wenn die Serverroutine das Kontexthandle geschlossen hat, weiß der Client nichts davon, da der Aufruf nicht erfolgreich ist. Die weitere Verwendung des Kontexthandles führt zu einem RPC_X_SS_CONTEXT_MISMATCH Fehler auf dem Client. Wenn die Serverroutine das Kontexthandle nicht ändert, kann es weiterhin vom Client verwendet werden. Wenn die Serverroutine die im Serverkontext gespeicherten Informationen ändert, verwenden neue Aufrufe vom Client diese Informationen.

• Ein Nicht-NULL-Kontexthandle wird eingetroffen, und die Serverroutine schließt das Handle, aber entweder ist das Marshallen nach dem Marshallen des Kontexthandles fehlgeschlagen, oder die Verarbeitung nach dem Marshallen ist fehlgeschlagen.

  Das Kontexthandle wird geschlossen, und weitere Aufrufe durch diesen Client mit diesem Kontexthandle führen zu einem RPC_X_SS_CONTEXT_MISMATCH Fehler auf dem Client.

• Ein NULL-Kontexthandle wird eingetroffen, und der Server erstellt seinen Kontext für dieses Handle, aber entweder beim Marshallen nach dem Marshallen des Kontexthandles oder bei der Verarbeitung nach dem Marshallen ist ein Fehler aufgetreten.

  In diesem Fall ruft die RPC-Laufzeit die Ausführung für dieses Kontexthandle auf und bereinigt den RPC-Zustand für dieses Kontexthandle. Das Kontexthandle wird nicht auf der Clientseite erstellt.

• Ein Nicht-NULL-Kontexthandle wird eingetroffen, und der Server ändert entweder das Kontexthandle nicht, oder er ändert die im Serverkontext gespeicherten Informationen, und das Marshalling schlägt fehl, nachdem das Kontexthandle gemarst wurde.

  Neue Aufrufe vom Client verwenden das Kontexthandle, über das der Server verfügt.

• Ein NULL-Kontexthandle wird eingetroffen, und der Server legt es nicht auf NULL fest, aber der Aufruf schlägt fehl, bevor das Kontexthandle gemarst wird.

  In diesem Fall wird kein Kontexthandle auf dem Client erstellt.

• Ein Nicht-NULL-Kontexthandle wird eingetroffen, und der Server legt es auf NULL fest. Beim Marshallen tritt jedoch ein Fehler auf, bevor das Kontexthandle gemarst wird.

  In diesem Fall bleibt das Kontexthandle auf dem Server geschlossen, und der Client erhält RPC_X_SS_CONTEXT_MISMATCH Fehler, wenn er versucht, das Kontexthandle zu verwenden.

• Ein NULL-Kontexthandle wird auf dem Server eingetroffen, und der Server legt es auf ungleich NULL fest, aber beim Marshallen des Kontexthandles tritt ein Fehler auf.

  Das heruntergefahrene Kontexthandle soll aufgerufen werden, damit der Server sauber kann und kein Kontexthandle auf dem Client erstellt wird.

• Ein Nicht-NULL-Kontexthandle wird eingetroffen, und der Server ändert entweder das Kontexthandle nicht, oder er ändert die im Serverkontext gespeicherten Informationen, und das Marshallen schlägt fehl, bevor das Kontexthandle gemarst wird.

  Neue Aufrufe vom Client verwenden den Zustand auf dem Server.

• Ein Kontexthandle wird als Rückgabewert deklariert, und die Serverroutine gibt NULL für das Kontexthandle zurück, und das Marshallen schlägt fehl, bevor das Kontexthandle gemarst wird.

  In diesem Fall wird auf dem Client kein neuer Kontext erstellt.

• Ein Kontexthandle wird als Rückgabewert deklariert, und die Serverroutine gibt nicht NULL für das Kontexthandle zurück, und das Marshallen schlägt fehl, bevor das Kontexthandle gemarst wird.

  Die RPC-Laufzeit ruft die Herunterlaufroutine für das Kontexthandle auf, um ihr die Möglichkeit zu geben, sauber, und es wird kein neuer Kontext auf dem Client erstellt.