Je suis novice en WCF et en SOA. Je commence juste sur ceux-ci, j'ai un doute théorique:Comment la concurrence fonctionne-t-elle dans WCF?
Le client A a appelé un service et la logique est en cours d'exécution sur le serveur. Pendant que la logique s'exécute, un autre appel du client B arrive pour le même service.
À ce stade, qu'arrive-t-il à la logique en cours d'exécution pour le client A? Comment le service parvient-il à répondre aux demandes?
La réponse à votre question dépend de la liaison que vous utilisez. Deux paramètres contrôlent ce comportement: InstanceContextMode et ConcurrencyMode. Ces deux paramètres sont définis dans ServiceBehaviorAttribute. InstanceContextMode contrôle le mode d'instanciation du service.
Il a les valeurs suivantes:
PerCall - chaque fois que vous appelez le service, une nouvelle instance de service est créée. C'est le comportement par défaut pour les services exposés sur des liaisons qui n'utilisent pas de session de transport, de session fiable ou de session de sécurité => BasicHttpBinding, WebHttpBinding. PerSession - chaque fois que vous appelez le service à partir de la nouvelle instance de proxy, une nouvelle instance de service est créée. Tout appel ultérieur provenant du même proxy est géré par la même instance de service (l'instance réside sur le serveur). Par défaut, l'appel suivant doit être effectué dans les 10 minutes (receiveTimeout) ou l'instance de service est libérée. C'est le comportement par défaut par défaut pour les services exposés sur la liaison qui utilisent la session de transport, la session fiable ou la session de sécurité => WSHttpBinding (paramètre par défaut utilise la session de sécurité), NetTcpBinding, NetNamedPipeBinding.
Unique - une seule instance du service existe et gère tous les appels.Cette instance de service peut être créée lorsque l'hôte démarre ou lorsque le service est appelé pour la première fois.
Maintenant, vous savez comment les instances sont créées. Le second paramètre ConcurrencyMode contrôle le nombre de threads concurrents pouvant accéder à une instance unique. Chaque requête est toujours gérée dans un fil distinct.
Un seul thread peut accéder à l'instance de service. C'est le comportement par défaut. Reentrant - un thread peut accéder au service mais il peut libérer le verrou et permettre à un autre thread d'utiliser l'instance pendant que le premier thread sera bloqué. Ceci est utilisé dans le scénario de rappel.
Plusieurs threads multiples peuvent accéder à l'instance de service.
Maintenant vous savez comment l'instance peut être utilisée simultanément. Permet de jeter un coup d'oeil sur certaines combinaisons:
Percall instanciation + simple accès simultané - scénario typique sans état. Les appels simultanés multiples sont autorisés.
PerCall instancing + Concurrence multiple - n'a pas de sens. Il se comporte toujours comme une concurrence unique. Instance PerSession + Concurrence unique - plusieurs appels simultanés sont autorisés, mais un seul appel de chaque mandataire peut être traité en même temps. Les autres appels sont mis en file d'attente.
PerSession instancing + Concurrence multiple - plusieurs appels simultanés sont autorisés. Plusieurs appels de chaque proxy peuvent accéder à la même instance en même temps. Vous devez effectuer une synchronisation manuelle de l'accès aux champs partagés dans l'instance de service.
Instance unique + Concurrence unique - seule une seule requête peut être traitée à la fois. Les autres demandes sont mises en file d'attente (délai d'attente par défaut: 30 secondes).
Instanciation unique + Concurrence multiple - plusieurs appels simultanés sont autorisés. Tous les appels accèdent à la même instance en même temps. Vous devez effectuer une synchronisation manuelle de l'accès aux champs partagés dans l'instance de service.
Bien le service exécute les demandes dans des threads séparés.
Ainsi, ils pourraient être exécutés en même temps.
Cela dépend de la valeur de la propriété ConcurrencyMode de l'attribut ServiceBehavior appliquée à l'implémentation du service. Si le mode ConcurrencyMode est Single, l'appel du client B attendra que l'appel du client A soit terminé; Si ConcurrencyMode est Multiple, les deux seront exécutés en même temps mais sur des threads séparés. Dans le cas contraire mis
, les paramètres par défaut de ConcurrencyMode à simple: http://msdn.microsoft.com/en-us/library/system.servicemodel.servicebehaviorattribute.concurrencymode.aspx
Vous pouvez également trouver la propriété InstanceContextMode utile pour comprendre et contrôler la façon dont plusieurs demandes de plusieurs clients sont traités: http://msdn.microsoft.com/en-us/library/system.servicemodel.servicebehaviorattribute.instancecontextmode.aspx
Cette réponse est incorrecte. Ce que vous décrivez est la combinaison de InstanceContextMode.Single et ConcurrencyMode.Single. Ce n'est pas un comportement par défaut. –
Vous pouvez contrôler l'accès simultané en utilisant le mode ConcurrencyMode et contrôlez comment les nouvelles connexions sont gérées via InstanceContextMode - ceci est le Microsoft documentation.
Le nombre de connexions simultanées peut également être limité - jetez un oeil à l'élément serviceThrottling dans votre configuration WCF.
Il existe des paramètres pour l'instance et la simultanéité, voir http://msdn.microsoft.com/en-us/library/ms731193.aspx pour plus de détails.
L'exécution de votre service WCF dans IIS prend en charge certains des problèmes de simultanéité.
Merci beaucoup pour la grande explication Ladislav! – Sandeep
[cet article] (http://blogs.msdn.com/b/rickrain/archive/2009/06/15/wcf-instancing-concurrency-and-throttling-part-1.aspx) indique que la valeur par défaut est 'PerSession' :( –
@Ladislav Mrnka - Donc pour 'PerSession instancing + Single Concurrency' - 1) cela signifie que deux proxys différents peuvent faire des appels simultanés, et le service peut les traiter simultanément? 2) Mais plusieurs appels d'un seul proxy seront traités un à la fois? – VoodooChild