J'ai créé un proxy de service Web avec la fonction "Ajouter une référence Web" de VS 2008 (C #). P>
La classe générée dérive de Puis-je stocker une seule instance de mon proxy dans un singleton? Est-ce que c'est le fil sûr? Existe-t-il de l'état entre les appels qui m'empêcheraient de le faire? P> SOAPHTTTPCLientProtocol code> P>
4 Réponses :
par ce lien: http: / /msdn.microsoft.com/en-us/library/system.web.services.protocols.soaphttpClientProtocol.aspx P>
en bas sous la «sécurité du fil», il est indiqué que ce type est le fil de sécurité. Je ne sais cependant pas que l'utiliser comme un singleton sera en sécurité. P>
Habituellement, pour des types non threadsafe, le libellé serait "tous les membres de la classe sont garantis pour être en sécurité. Tous les membres de l'instance ne sont pas garantis pour être en sécurité." Je suppose donc que "ce type est thread-coffre-fort" implique des membres de la classe et des instances.
ok je suis confus ... peut-être une meilleure question aurait été: "Créer une instance du proxy de service Web pour chaque appel à une méthode Web une performance Dower?" : P
Je suppose par "TYPE", ils signifient que le type (c'est-à-dire des informations de type), par opposition aux membres de la classe statique ou aux membres de l'instance, qui ne sont pas thread-coffre-fort.
J'ai écrit une autre réponse qui dit le contraire de la vôtre. Que tu penses est juste?
Non. Ce n'est pas un fil sûr. Le client doit être à l'état ouvert pour activer les appels. Un scénario simple où un thread contient client.Close () tandis qu'un autre essaie d'appeler une méthode échouera. P>
Cette classe n'a pas de méthode de près et n'a pas au moins depuis v3.0. Voir la réponse de Chrisw.
@Riversatya - La réponse a été postée il y a 8 ans
Oui, et c'est obsolète. Comme c'est la réponse acceptée, j'ai ajouté un pointeur à un sommet plus à jour.
MSDN dit que SOAPHTTPCLIENTPROTOCOL est le fil sûr: p>
Sécurité du thread forte> p> Ce type est le fil sûr. P> blockQuote>
pour une autre classe comme System.Windows.Forms qui n'est pas thread-coffre-fort, dit MSDN, P>
Sécurité du thread forte> p> Tous les membres publiques statiques (partagés dans Visual Basic) de ce type sont Sécurité du fil. Tous les membres de l'instance ne sont pas garantis Coffre-fort. P> blockQuote>
Voici un employé Microsoft / MSDN en disant (bien que sans garantie) qu'il s'agisse de fil-coffre-fort: P>
salut max, p>
Pour le proxy WebService, je pense que cela devrait être thread-coffre-fort comme le .NET La classe proxy générée est dérivé du "SoaphttpClientProtocol" classe qui est marquée comme fil-coffre-fort dans le document: p>
CLASSE SOAPHTTPCLIENTPROTOCOL H1>
Par conséquent, il devrait être sûr de l'utiliser dans le contexte multi-thread aussi longtemps Comme vous n'avez pas ajouté manuellement un membre contextuel dans le classe proxy dérivée. Pensez-vous? P>
sincèrement, p>
Steven Cheng P>
Microsoft MSDN en ligne Prise en charge P>
Cette publication est fournie "tel quel" sans garantie et ne confère aucun droits. p> blockQuote>
-1: Vous discutez d'une technologie héritée et vous reliez à un article de .NET 1.1.
Le premier lien que j'ai donné est à la documentation actuelle (.NET 4.5) pour la classe: qui dit toujours qu'il est en sécurité. Le dernier lien que j'ai donné est une citation directe d'un ancien poste de forum d'un employé de MSFT (pour confirmer la manière dont la documentation MSDN doit être comprise).
Aucun desquels des déclarations ne contredisent ce que j'ai dit.
@Johnsaunders Avez-vous une suggestion pour Améliorer cette réponse?
Je vois: Peut-être que ce n'est pas la réponse que vous n'aimez pas spécifiquement, c'est la question / sujet (qui concerne la "technologie héritée").
Avec respect, je pense que cliquer sur le lien "Supprimer" serait une amélioration.
@Johnsaunders Je pensais que je devrais le poster, corriger les informations erronées: parce que, jusqu'à mon savoir que je sache, Cette réponse était tort.
Ouais, je ne sais vraiment pas. Je suppose que le libellé peut être pris à la valeur de la face: ce type est le fil de sécurité - à la fois de la classe et des objets instanciés. Poignez à travers le code dans le réflecteur, je n'ai pas pu trouver quoi que ce soit une condition de race. Je ne sais pas ce que John est grincheux. La question est si SOPHTTTPCLientProtocol est en sécurité; pas si pense que les gens devraient l'utiliser.
@Johnsaunders Je suis plus intéressé à savoir comment utiliser le nouveau ClientBase
@Ianboyd: Je pense que vous prenez un risque important en fonction du code qui est tout sauf supporté d'être en sécurité. Et si cela s'avère que est i> une condition de race? Vous réalisez-vous que Microsoft ne le réparera pas? En outre, juste parce que la classe de base est en sécurité, cela n'implique pas que les classes proxy générées qui en dérivent sont du fil de sécurité.
@Chrisw: J'ai effectivement essayé de supprimer mon bowvote, mais je ne peux pas avant de modifier.
@Johnsaunders merci; Mais je n'ai pas de modifier à faire, à cette réponse: je veux réellement (apprendre à) utiliser la base clientBase (en toute sécurité). Je n'ai trébubli que sur cette (vieille) question via Google Google.com /Search?q=asp.net+SoPoap+Thread-safe
Certaines personnes ne peuvent pas passer à la dernière et au plus grand et sont bloquées par la "technologie héritée". Garde cela à l'esprit.
ASMX est une technologie héritée et ne doit pas être utilisée pour un nouveau développement. WCF ou ASP.NET Web API devraient être utilisés pour tout nouveau développement de clients de service Web et de serveurs. Un indice: Microsoft a retiré le ASMX Forum sur MSDN.