7
votes

Httpmodule est-il partagé parmi les threads de travail?

Dois-je verrouiller l'accès aux membres de l'instance?

Exemple: P>

public class HttpModule : IHttpModule
{
    //...

    Dictionary<int, int> foo;

    void UseFoo(int a, int b)
    {
        foo[a] = b;
    }
}


0 commentaires

4 Réponses :


4
votes

Ce n'est pas cristal clair pour moi jusqu'à présent de la documentation MSDN, mais j'ai trouvé un Poste du forum de quelqu'un qui prétend connaître la réponse . On dirait que vous ne devriez pas vous attendre à Bad Stuff pour arriver avec votre implémentation, mais vous devez savoir que l'état FOO ne sera pas nécessairement partagé à tous les résultats depuis que votre httpmodule sera créé une fois par httpApplication que IIS choisit de rester dans sa piscine.


3 commentaires

Oui, il réutilise l'instance parmi de nombreuses demandes différentes. Mais la question est de savoir si elle réduit l'instance entre différents threads.


D'après ce que je peux dire: Oui, mais pas en même temps. Un httpApplication semble être attribué à une demande donnée pendant la durée de cette demande.


D'accord merci. J'attendrai que quelqu'un comment le sait exactement cela, car je vais utiliser ce code dans l'environnement de production, et je serai difficile à déboguer.



1
votes

J'ai récemment trouvé un article qui touche légèrement sur cette question: http://www.dominicpettifer.co.uk/blog/41/ihttpmodule-gotchas---the-init--method-can-get-called-multiple-times

Cela ne 'T mentionne les threads, mais dit seulement que le processus ouvrier sera

Instanciez autant de nombreux httpApplication objets comme il pense qu'il a besoin, alors Ça va les ponder pour la performance raisons, réutiliser des instances comme neuves Les demandes entrent avant de les envoyer retour dans la piscine.

Suivre le code dans le lien, vous pouvez être sûr que votre code init est exécuté une fois de manière filaire: xxx

i ' VE Vous avez eu le sens de configurer une application de test pour l'exécuter et de le tester, juste pour voir si c'est vrai, mais je n'ai pas eu le temps.


1 commentaires

Merci pour votre réponse. Cela vérifie si cela est partagé maintenant. J'ai besoin de le savoir exactement, car comme je me suis dit ci-dessus, je l'utiliserai dans l'environnement de la production et que ce sera vraiment douloureux si cela est modifié, par exemple pendant une mise à jour de .NET Framework ou IIS.



1
votes

L'article posté par Jim est intéressant, mais comme Jim dit qu'il ne mentionne rien de la sécurité du fil.

Je suppose que vous n'auriez besoin que du mécanisme de verrouillage si vous initialisez les membres statiques ou effectuez des initialisations «une seule fois», c'est-à-dire initialiser une ressource statique.

Je ne pouvais pas conclure de MSDN ni l'article mentionné par Jim que nous avons besoin du mécanisme de verrouillage lors de l'initialisation des variables de classe non statiques.


0 commentaires

2
votes

Je voulais offrir ici mes résultats liés à cette question comme je l'ai observé dans IIS6:

J'ai beaucoup abordé de manière approfondie dans IIS6 et j'ai trouvé des résultats intéressants en utilisant Log4Net et la réflexion pour capturer l'historique d'exécution. Ce que j'ai trouvé, c'est qu'il y a une "gestion de thread" étendue dans les coulisses. Il semble qu'il existe une série de threads «primaire» correspondant à 1: 1 à httpApplication . Ces threads ne manipulent pas exclusivement le pipeline pour votre demande. Divers sous-threades différents peuvent être appelés lorsque ces instances sont consultées. Les nouvelles demandes et demandes de ressources ultérieures utilisées par votre demande semblent partager certaines informations persistantes relatives à votre demande d'origine, mais ne sont jamais manipulées entièrement par le fil initial indiquant un type de relation. Je ne pouvais pas discerner aucun modèle concret (autre que ce que j'ai décrit précédemment) sur quels éléments ont été divisés à d'autres threads car il était apparemment aléatoire. Ma conclusion à cette preuve est qu'il existe un concept de mise en commun hiérarchique? se produisant lorsque certains sous-groupes d'éléments de référence inconnus sont hérités dans les fils d'enfants par la référence parent.

Alors qu'une réponse, je dirais que httpmodules est partagé entre les threads. En termes de valeurs d'instance de verrouillage, ceci serait applicable si les valeurs s'appliquaient à toutes les demandes qui utilisent le module et doivent maintenir un État. Je pouvais voir que cela était utile s'il tente de maintenir des valeurs d'instance d'état coûteux de déterminer afin de pouvoir être réutilisés dans des demandes suivantes.

Ce numéro me troublait depuis quelque temps, j'espère que cette information aide quelqu'un.


0 commentaires