Partager via

Sessions, instanciation et accès concurrentiel

Une session est une corrélation de tous les messages envoyés entre deux points de terminaison. L’instanciation fait référence au contrôle de la durée de vie des objets de service définis par l’utilisateur et de leurs objets associés InstanceContext . La concurrence est le terme donné au contrôle du nombre de threads exécutés dans un InstanceContext au même moment.

Cette rubrique décrit ces paramètres, leur utilisation et les différentes interactions entre elles.

Séances

Lorsqu’un contrat de service définit la propriété ServiceContractAttribute.SessionMode à SessionMode.Required, ce contrat indique que tous les appels (autrement dit, les échanges de messages sous-jacents qui prennent en charge les appels) doivent faire partie de la même conversation. Si un contrat spécifie qu’il autorise les sessions, mais n’en nécessite pas, les clients peuvent se connecter et établir une session ou non. Si la session se termine et qu'un message est envoyé sur le même canal basé sur session, une exception est levée.

Les sessions WCF ont les principales fonctionnalités conceptuelles suivantes :

  • Ils sont lancés explicitement et arrêtés par l’application appelante.

  • Les messages remis pendant une session sont traités dans l’ordre dans lequel ils sont reçus.

  • Les sessions mettent en corrélation un groupe de messages dans une conversation. La signification de cette corrélation est une abstraction. Par exemple, un canal basé sur une session peut mettre en corrélation des messages basés sur une connexion réseau partagée, tandis qu’un autre canal basé sur une session peut mettre en corrélation des messages basés sur une balise partagée dans le corps du message. Les fonctionnalités qui peuvent être dérivées de la session dépendent de la nature de la corrélation.

  • Il n’existe aucun magasin de données général associé à une session WCF.

Si vous connaissez la System.Web.SessionState.HttpSessionState classe dans ASP.NET applications et les fonctionnalités qu’elle fournit, vous pouvez remarquer les différences suivantes entre ce type de session et les sessions WCF :

  • ASP.NET sessions sont toujours initiées par le serveur.

  • ASP.NET sessions sont implicitement non ordonnées.

  • ASP.NET sessions fournissent un mécanisme de stockage de données général entre les requêtes.

Les applications clientes et les applications de service interagissent de différentes manières avec les sessions. Les applications clientes lancent des sessions, puis reçoivent et traitent les messages envoyés au sein de la session. Les applications de service peuvent utiliser des sessions comme point d’extensibilité pour ajouter un comportement supplémentaire. Pour ce faire, vous pouvez soit travailler directement avec le InstanceContext, soit implémenter un fournisseur de contexte d’instance personnalisé.

Instanciation

Le comportement d’instanciation (défini par la propriété ServiceBehaviorAttribute.InstanceContextMode) contrôle la manière dont le InstanceContext est créé en réponse aux messages entrants. Par défaut, chacun InstanceContext est associé à un objet de service défini par l’utilisateur. Par conséquent ,dans le cas par défaut, la définition de la InstanceContextMode propriété contrôle également l’instanciation des objets de service définis par l’utilisateur. L’énumération InstanceContextMode définit les modes d’instanciation.

Les modes d’instanciation suivants sont disponibles :

  • PerCall: un nouvel InstanceContext objet (et par conséquent un objet de service) est créé pour chaque demande cliente.

  • PerSession : un nouveau InstanceContext (et par conséquent un objet de service) est créé pour chaque nouvelle session cliente et est conservé pendant toute la durée de vie de celle-ci (cela requiert une liaison capable de prendre les sessions en charge).

  • Single: un seul InstanceContext (et par conséquent un objet de service) gère toutes les demandes clientes pour la durée de vie de l’application.

L’exemple de code suivant montre la valeur par défaut InstanceContextMode , PerSession définie explicitement sur une classe de service.

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

Et tandis que la propriété ServiceBehaviorAttribute.InstanceContextMode contrôle la fréquence de publication de InstanceContext, les propriétés OperationBehaviorAttribute.ReleaseInstanceMode et ServiceBehaviorAttribute.ReleaseServiceInstanceOnTransactionComplete contrôlent le moment où l’objet de service est libéré.

Services singleton connus

Une variante des objets de service à instance unique est parfois utile : vous pouvez créer vous-même un objet de service et créer l’hôte de service à l’aide de cet objet. Pour ce faire, vous devez également affecter ServiceBehaviorAttribute.InstanceContextMode à la propriété Single , sans quoi une exception est levée lorsque l'hôte de service est ouvert.

Utilisez le ServiceHost(Object, Uri[]) constructeur pour créer un tel service. Il offre une alternative à l’implémentation d’une instance d’objet personnalisée System.ServiceModel.Dispatcher.IInstanceContextInitializer lorsque vous souhaitez fournir une instance d’objet spécifique à utiliser par un service singleton. Vous pouvez utiliser cette surcharge lorsque votre type d’implémentation de service est difficile à construire (par exemple, s’il n’implémente pas de constructeur public sans paramètre).

Notez que lorsqu’un objet est fourni à ce constructeur, certaines fonctionnalités liées au comportement d’instanciation windows Communication Foundation (WCF) fonctionnent différemment. Par exemple, l’appel InstanceContext.ReleaseServiceInstance n’a aucun effet lorsqu’une instance d’objet singleton est fournie. De même, tout autre mécanisme de libération d'instance est ignoré. Le ServiceHost agit toujours comme si la propriété OperationBehaviorAttribute.ReleaseInstanceMode était définie sur ReleaseInstanceMode.None pour toutes les opérations.

Partage d’objets InstanceContext

Vous pouvez également contrôler le canal ou l’appel avec session associé à l’objet InstanceContext en effectuant cette association vous-même.

Concurrence

La concurrence est le contrôle du nombre de threads actifs dans un InstanceContext à un moment donné. Ceci est contrôlé en utilisant la ServiceBehaviorAttribute.ConcurrencyMode avec l’énumération ConcurrencyMode.

Les trois modes d’accès concurrentiel suivants sont disponibles :

  • Single: chaque contexte d’instance est autorisé à avoir un maximum d’un thread de traitement des messages dans le contexte de l’instance à la fois. Les autres threads souhaitant utiliser le même contexte d’instance doivent bloquer jusqu’à ce que le thread d’origine quitte le contexte d’instance.

  • Multiple: chaque instance de service peut avoir plusieurs threads de traitement des messages simultanément. Pour utiliser ce mode, l'implémentation de service doit être « thread-safe ».

  • Reentrant: Chaque instance de service traite un message à la fois, mais accepte des appels d'opération réentrants. Le service accepte uniquement ces appels lorsqu’il appelle via un objet client WCF.

Remarque

Comprendre et développer du code qui utilise en toute sécurité plusieurs threads peut être difficile à écrire correctement. Avant d’utiliser Multiple ou Reentrant de valeurs, assurez-vous que votre service est correctement conçu pour ces modes. Pour plus d’informations, consultez ConcurrencyMode.

L'utilisation de l'accès concurrentiel est associée au mode d'instanciation. Dans l’instanciation PerCall, la concurrence n’est pas pertinente, car chaque message est traité par un nouvel objet InstanceContext et, par conséquent, il n’y a jamais plusieurs threads actifs dans l’objet InstanceContext.

L’exemple de code suivant illustre la définition de la ConcurrencyMode propriété sur Multiple.

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

Sessions Interagissent avec les paramètres InstanceContext

Les sessions et InstanceContext interagissent en fonction de la combinaison de la valeur de l’énumération SessionMode dans un contrat, et de la propriété ServiceBehaviorAttribute.InstanceContextMode sur l’implémentation du service, qui contrôle l’association entre les canaux et les objets de service spécifiques.

Le tableau suivant présente le résultat d'un canal entrant prenant ou non en charge les sessions en fonction de la combinaison des valeurs de la propriété ServiceContractAttribute.SessionMode et de la propriété ServiceBehaviorAttribute.InstanceContextMode d'un service.

Valeur InstanceContextMode Required Allowed NotAllowed
PerCall - Comportement avec canal de session : une session et InstanceContext pour chaque appel.
- Comportement avec canal sans session : une exception est levée.		 - Comportement avec canal de session : une session et InstanceContext pour chaque appel.
- Comportement avec canal sans session : InstanceContext pour chaque appel.		 - Comportement avec canal de session : une exception est levée.
- Comportement avec canal sans session : InstanceContext pour chaque appel.
PerSession - Comportement avec canal de session : une session et InstanceContext pour chaque canal.
- Comportement avec canal sans session : une exception est levée.		 - Comportement avec canal de session : une session et InstanceContext pour chaque canal.
- Comportement avec canal sans session : InstanceContext pour chaque appel.		 - Comportement avec canal de session : une exception est levée.
- Comportement avec canal sans session : InstanceContext pour chaque appel.
Célibataire - Comportement avec canal de session : une session et un seul InstanceContext pour tous les appels.
- Comportement avec canal sans session : une exception est levée.		 - Comportement avec canal de session : une session et InstanceContext pour le singleton créé ou spécifié par l’utilisateur.
- Comportement avec un canal sans session : InstanceContext pour le singleton créé ou spécifié par l’utilisateur.		 - Comportement avec canal de session : une exception est levée.
- Comportement avec un canal sans session : InstanceContext pour chaque singleton créé ou pour le singleton spécifié par l’utilisateur.

Voir aussi