Sémantique d’échec pour les handles de contexte

Cette rubrique traite de la sémantique des défaillances pour les handles de contexte.

Sémantique d’échec lors de la fermeture du handle de contexte échoue

Imaginez qu’une application cliente tente de fermer un handle de contexte ouvert sur le serveur, sans arrêter le processus client. En outre, supposons que l’appel au serveur pour fermer le handle de contexte échoue (par exemple, le client est hors mémoire). La bonne façon de gérer cette situation consiste à appeler la fonction RpcSsDestroyClientContext. Dans ce cas, le client nettoie son côté du handle de contexte et ferme de manière abandonnée la connexion au serveur. Étant donné que la connexion est vraiment un pool de connexions (voir RPC et le réseau), qui est comptabilisé par référence avec une référence pour chaque handle de liaison ou de contexte ouvert, en détruisant le handle de contexte en appelant la fonction RpcSsDestroyClientContext ne détruit pas réellement la connexion. Au lieu de cela, il décrémente le nombre de références pour le pool de connexions. Pour que les connexions dans le pool soient fermées, le client doit fermer tous les handles de liaison et les handles de contexte à ce serveur à partir du processus client. Ensuite, toutes les connexions dans le pool sont fermées, et le mécanisme d’exécution du serveur est lancé et nettoie.

Sémantique d’échec pendant le changement d’état du handle de contexte

Les informations de cette section font référence aux plateformes Windows XP et ultérieures.

Les handles de contexte sont simplement des paramètres pour une fonction. Toutes les modifications apportées à l’état d’un handle de contexte se produisent lorsque les paramètres sont marshalés ou non délimités. Par exemple, si un client ouvre un handle de contexte (le modifie de null ennull), l’exécution RPC n’ouvre pas réellement la partie RPC du handle tant que les arguments ne sont pas marshalés pour l’envoi au client. Les défaillances peuvent se produire pendant l’intermédiaire. En raison d’une variété de conditions réseau ou de ressources faibles possibles, la transmission du paquet au client peut échouer. Ou la routine du serveur peut lever une exception lors de la tentative de modification d’un handle de contexte. Dans ces situations ou d’autres situations d’échec, le client et le serveur peuvent obtenir des vues incohérentes du handle de contexte. Cette section explique la règle de l’état du handle de contexte et la responsabilité du code client et serveur pendant différentes conditions d’échec.

• Une NULL handle de contexte arrive, mais la routine du serveur rencontre un échec et lève une exception.

  Il incombe à la routine du serveur de nettoyer tout état lié au handle de contexte qu’il a peut-être créé. Le temps d’exécution RPC nettoie son état.

• Un handle de contexte denull non- arrive, mais la routine du serveur rencontre un échec et lève une exception.

  Si la routine du serveur a fermé le handle de contexte, le client ne le sait pas, car l’appel ne réussit pas ; une autre utilisation du handle de contexte entraîne une erreur RPC_X_SS_CONTEXT_MISMATCH sur le client. Si la routine du serveur ne modifie pas le handle de contexte, le client peut toujours l’utiliser. Si la routine du serveur modifie les informations stockées dans le contexte du serveur, les nouveaux appels du client utilisent ces informations.

• Un handle de contexte nonNULL arrive et la routine du serveur ferme le handle, mais le marshaling après l’échec du handle de contexte ou le traitement après l’échec du marshaling.

  Le handle de contexte est fermé et d’autres appels par ce client utilisant ce handle de contexte entraînent une erreur RPC_X_SS_CONTEXT_MISMATCH sur le client.

• Un null handle de contexte arrive et le serveur crée son contexte pour ce handle, mais le marshaling après l’échec du handle de contexte ou le traitement après l’échec du marshaling.

  Dans ce cas, l’heure d’exécution RPC appelle l’exécution de ce handle de contexte et nettoie l’état RPC de ce handle de contexte. Le handle de contexte ne sera pas créé côté client.

• Un handle de contexte non-NULL arrive, et le serveur ne modifie pas le handle de contexte ou modifie les informations stockées dans le contexte du serveur et le marshaling échoue une fois le handle de contexte marshalé.

  Les nouveaux appels du client utilisent le handle de contexte dont dispose le serveur.

• Un handle de contexte NULL arrive et le serveur ne le définit pas sur une valeur autre que NULL, mais l’appel échoue avant que le handle de contexte ne soit marshalé.

  Dans ce cas, aucun handle de contexte n’est créé sur le client.

• Un handle de contexte nonNULL arrive et le serveur le définit sur NULL, mais le marshaling échoue avant que le handle de contexte ne soit marshalé.

  Dans ce cas, le handle de contexte reste fermé sur le serveur et le client obtient RPC_X_SS_CONTEXT_MISMATCH erreurs lorsqu’il tente d’utiliser le handle de contexte.

• Un handle de contexte NULL arrive sur le serveur et le serveur le définit surNULL, mais le marshaling échoue avant que le handle de contexte ne soit marshalé.

  L’exécution du handle de contexte doit être appelée afin que le serveur puisse nettoyer et qu’aucun handle de contexte ne soit créé sur le client.

• Un handle de contexte non-NULL arrive et le serveur ne modifie pas le handle de contexte, ou modifie les informations stockées dans le contexte du serveur et le marshaling échoue avant que le handle de contexte ne soit marshalé.

  Les nouveaux appels du client utilisent l’état sur le serveur.

• Un handle de contexte est déclaré comme une valeur de retour, et la routine du serveur retourne NULL pour le handle de contexte et le marshaling échoue avant que le handle de contexte ne soit marshalé.

  Dans ce cas, aucun nouveau contexte n’est créé sur le client.

• Un handle de contexte est déclaré comme une valeur de retour, et la routine du serveur retourne desNULL non pour le handle de contexte et le marshaling échoue avant que le handle de contexte ne soit marshalé.

  L’heure d’exécution RPC appelle la routine d’exécution du handle de contexte pour lui donner la possibilité de nettoyer, et aucun nouveau contexte n’est créé sur le client.