Lorsque vous utilisez .NET Remoting à l'aide d'objets activés par le serveur, quels sont les compromis entre SingleCall et l'activation de Singleton?

Question

J'essaie de discerner la différence entre les méthodes d'activation SingleCall et Singleton lors de l'implémentation d'un serveur pour héberger un objet en utilisant .NET Remoting. Il semblerait que SingleCall ait l'inconvénient de devoir construire et nettoyer un objet pour chaque appel côté client, alors que Singleton a la limitation de ne pouvoir traiter qu'un nombre limité de requêtes simultanées. Je cherche à rendre la performance aussi bonne que possible. Lequel devrais-je choisir?

Answer 1

Par défaut, vous devez utiliser SingleCall. De plus, gardez à l'esprit que lorsque vous utilisez des objets SingleCall, vous ne pouvez pas partager l'état d'un appel à l'autre.

Je trouve ce site une bonne ressource en matière de .NET Remoting: http://www.thinktecture.com/resourcearchive/net-remoting-faq/remotingusecases

Answer 2

Vous avez raison. SingleCall construit l'objet pour chaque appel et peut accepter plusieurs demandes simultanées, mais les données ne peuvent pas être partagées entre les appels, tandis que Singleton construit un seul objet pour gérer plusieurs appels permettant le partage de données, mais limite les connexions simultanées. Cependant, il y a des ajustements que vous pouvez faire si vous avez un concept de la façon de construire des objets thread-safe. Tout d'abord, je suggère d'utiliser le singleton car il est créé une seule fois pour beaucoup. Cela a également l'avantage de vous permettre de stocker des informations et de les partager entre les utilisateurs qui s'y connectent sans avoir à toucher constamment un magasin extérieur. Deuxièmement, je voudrais ajouter en ajoutant le ConcurrencyMode = ConcurrencyMode.Multiple dans les ServiceBehaviors de votre service. Cela permet à plusieurs utilisateurs de frapper votre singleton simultanément. Troisièmement, nettoyez tout code qui rendrait cette classe non thread thread. Vous devez verrouiller l'objet lors de l'accès aux variables locales auxquelles plusieurs threads peuvent accéder simultanément.

Beaucoup de bonnes informations sur ces sujets peuvent être trouvés ici:

http://msdn.microsoft.com/en-us/library/ms731193.aspx