Dans mon côté service WCF, j'ai une XXService qui a défini comme:WCF InstanceContextMode unique et Async communication
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)]
XXService est hébergé dans une application gérée en utilisant ServiceHost (classe, adresse). Je fournis une classe et pas d'interface puisque ma classe a un constructeur personnalisé. Mon service supposé faire des opérations parallèles, et ne doit pas bloquer les appels.
J'utilise le modèle IAsyncResult, sur mon BeginOperation j'envoie le travail réel à ThreadPool.QueueUserWorkItem pour faire le travail afin d'éviter de bloquer mon XXService.
Est-ce que ce motif est correct?
Ce que fait le service est synchronisé.
Mon concerne est que je devrais utiliser PerCall? Quels sont les avantages d'utiliser PerCall au lieu de faire ce que j'ai fait (serait-il préférable d'utiliser Unity et WCF parce que mon XXService a besoin d'un constructeur personnalisé)?
Si une instance de mon XXService lance une exception non gérée, le ServiceHost sera bloqué. mais cela n'a rien à voir avec InstanceContext single/percall.
merci, je suis familier avec cela, ils n'expliquer ce qui est erroné dans mon approche VS Percall – ilansch
Ceci est ma compréhension de votre problème .. 1. Vous avez une instance unique où vous répondez à chaque demande en ayant un travailleur IAsync distinct. 2. Vous voulez utiliser PerCall pour améliorer les performances .. ai-je raison? – Mullaly
Je voudrais savoir si l'utilisation de l'instance unique et l'envoi à Threadpool du travail, fera la même chose que PerCall sans instancier de nombreuses instances de service. De cette façon, j'aurai une instance unique, cela évitera de bloquer cette instance puisque j'envoie du travail au pool de threads. Il n'y aura pas beaucoup de XXservices pour chaque appel. – ilansch