Fehlersemantik für Kontexthandles

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

Fehlersemantik beim Schließen des Kontexthandle-Fehlers

Stellen Sie sich vor, eine Clientanwendung versucht, einen kontextabhängigen Handle zu schließen, der auf dem Server geöffnet wurde, ohne den Clientprozess herunterzufahren. Gehen Sie außerdem davon aus, dass der Aufruf des Servers zum Schließen des Kontexthandle fehlschlägt (z. B. liegt der Client nicht im Arbeitsspeicher). Die richtige Möglichkeit zur Behandlung dieser Situation ist das Aufrufen der RpcSsDestroyClientContext--Funktion. In einem solchen Fall bereinigt der Client seine Seite des Kontexthandles und schließt die Verbindung mit dem Server abbruchiv. Da es sich bei der Verbindung wirklich um einen Verbindungspool handelt (siehe RPC und), der mit einem Verweis für jede geöffnete Bindung oder ein Kontexthandle gezählt wird, zerstört das Kontexthandle durch Aufrufen der RpcSsDestroyClientContext--Funktion die Verbindung nicht tatsächlich. Stattdessen wird die Referenzanzahl für den Verbindungspool erhöht. Damit Verbindungen im Pool geschlossen werden, muss der Client alle Bindungshandles und Kontexthandles vom Clientprozess an diesen Server schließen. Dann werden alle Verbindungen im Pool geschlossen, und der Serverausführungsmechanismus wird initiiert und bereinigt.

Fehlersemantik beim Ändern des Status 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 Kontexthandle treten auf, wenn Parameter gemarstet oder nichtmarsiert werden. Wenn ein Client z. B. ein Kontexthandle öffnet (ändert es von NULL in nicht-NULL), wird der RPC-Laufzeitbereich des Handles erst geöffnet, wenn die Argumente zum Senden an den Client gemarstet werden. Fehler können während der Zwischenzeit auftreten. Aufgrund einer Vielzahl möglicher Netzwerk- oder geringer Ressourcenbedingungen kann die Übertragung des Pakets an den Client fehlschlagen. Oder die Serverroutine löst möglicherweise eine Ausnahme aus, während Sie versuchen, ein Kontexthandle zu ändern. In diesen oder anderen Fehlersituationen kann der Client und der Server inkonsistente Ansichten des Kontexthandles erhalten. In diesem Abschnitt wird die Regel für den Status des Kontexthandles sowie die Verantwortung für 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 Kontexthandle-bezogenen Zustände zu bereinigen, die möglicherweise erstellt wurden. Die RPC-Laufzeit bereinigt ihren Zustand.

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

  Wenn die Serverroutine das Kontexthandle geschlossen hat, weiß der Client nicht darüber, da der Aufruf nicht erfolgreich ist. Die weitere Verwendung des Kontexthandle führt zu einem RPC_X_SS_CONTEXT_MISMATCH Fehler auf dem Client. Wenn die Serverroutine das Kontexthandle nicht ändert, kann der Client ihn weiterhin verwenden. Wenn die Serverroutine die im Serverkontext gespeicherten Informationen ändert, verwenden neue Aufrufe des Clients diese Informationen.

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

  Das Kontexthandle wird geschlossen, und weitere Aufrufe dieses Clients 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 marshallen, nachdem das Kontexthandle gemarstet wurde, oder die Verarbeitung nach dem Marshaling fehlgeschlagen ist.

  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 clientseitiger Seite erstellt.

• Ein nichtNULL- Kontexthandle eingeht, und der Server ändert entweder nicht den Kontexthandle, oder er ändert die im Serverkontext gespeicherten Informationen, und Marshalling schlägt fehl, nachdem das Kontexthandle gemarstet wurde.

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

• Ein NULL- Kontexthandle wird eingetroffen, und der Server legt ihn nicht auf einen anderen Wert als NULL-fest, aber der Aufruf schlägt fehl, bevor das Kontexthandle gemarstet wird.

  In diesem Fall wird kein Kontexthandle auf dem Client erstellt.

• Ein nichtNULL- Kontexthandle wird eingetroffen, und der Server legt ihn auf NULL-fest, aber Marshalling schlägt fehl, bevor das Kontexthandle gemarstet wird.

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

• Ein NULL- Kontexthandle wird auf dem Server eingetroffen, und der Server legt ihn auf nicht-NULL-fest, aber Marshaling schlägt fehl, bevor das Kontexthandle gemarstet wird.

  Die Ausführung des Kontexthandles besteht darin, aufgerufen zu werden, damit der Server bereinigt werden kann, und es wird kein Kontexthandle auf dem Client erstellt.

• Ein nichtNULL- Kontexthandle wird eingetroffen, und der Server ändert weder das Kontexthandle noch die im Serverkontext gespeicherten Informationen, und Marshaling schlägt fehl, bevor das Kontexthandle gemarstet wird.

  Neue Aufrufe vom Client verwenden den Status auf dem Server.

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

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

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

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