¿HttpModule se comparte entre los hilos de trabajo?

Question

¿Debo bloquear el acceso a los miembros de la instancia?

Ejemplo:

public class HttpModule : IHttpModule 
{ 
    //... 

    Dictionary<int, int> foo; 

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

Answer 1

No es claro para mí hasta ahora a partir de la documentación de MSDN, pero he encontrado un forum post from someone who claims to know the answer. Parece que no debe esperar que cosas malas sucedan con su implementación, pero debe tener en cuenta que el estado de foo no necesariamente se compartirá en todos los resultados ya que HttpModule se creará una vez por que IIS elige mantener en su grupo.

Answer 2

poco encontré un artículo que aborda esta pregunta un poco: http://www.dominicpettifer.co.uk/Blog/41/ihttpmodule-gotchas---the-init---method-can-get-called-multiple-times

No menciona las discusiones, pero sólo dice que el proceso de trabajo se

instantiate tantos objetos como HttpApplication cree que es necesario, luego los agrupará por razones de rendimiento , reutilizando instancias a medida que las nuevas solicitudes entren antes de enviarlas de vuelta al grupo.

Siguiendo el código en el enlace, puede estar seguro de que su código de inicio se ejecuta una vez de una manera segura para los subprocesos:

private static bool HasAppStarted = false; 
private readonly static object _syncObject = new object(); 

public void Init(HttpApplication context) 
{ 
    if (!HasAppStarted) 
    { 
     lock (_syncObject) 
     { 
      if (!HasAppStarted) 
      { 
       // Run application StartUp code here 

       HasAppStarted = true; 
      } 
     } 
    } 
} 

he tenido la intención de establecer una aplicación de prueba ejecutar esto y probarlo, solo para ver si es cierto, pero no he tenido tiempo.

Answer 3

El artículo publicado por Jim es interesante, pero como Jim dice que no menciona nada sobre la seguridad de las hebras.

Supongo que solo necesitaría el mecanismo de bloqueo si está inicializando miembros estáticos o realizando inicializaciones "solo una vez", es decir, inicializando un recurso estático.

No pude concluir de MSDN ni el artículo mencionado por Jim que necesitamos el mecanismo de bloqueo al inicializar las variables de clase no estáticas.

Answer 4

que quería ofrecer aquí mis hallazgos relacionados a esta pregunta como he observado en IIS6:

he estado tratando con este tema extensamente en IIS6 y han encontrado algunos resultados interesantes que utilizan log4net y reflexión para capturar historial de ejecución . Lo que he encontrado es que hay una extensa "gestión de hilos" detrás de escena. Parece que hay una serie 'primaria' de hilos que corresponde de 1: 1 a HttpApplication. Sin embargo, estos hilos no manejan exclusivamente la tubería para su solicitud. Se pueden llamar varios sub-hilos diferentes cuando se accede a estas instancias. Las nuevas solicitudes y solicitudes de recursos posteriores utilizadas por su aplicación parecen compartir cierta información persistente relacionada con su solicitud original, pero nunca se manejan del todo por el hilo inicial que indica algún tipo de relación. No pude discernir ningún patrón concreto (aparte de lo que describí anteriormente) en cuanto a qué elementos se dividen en otros hilos, ya que era aparentemente aleatorio. Mi conclusión a esta evidencia es que hay algún concepto de agrupamiento jerárquico? que ocurre cuando se hereda un subconjunto desconocido de elementos de referencia en los hilos hijo a través de la referencia principal.

Así que como una respuesta yo diría que HttpModulesson compartidos entre hilos. En términos de valores de instancia de bloqueo, esto sería aplicable si los valores se aplican a todas las solicitudes que usan el módulo y deben mantener algún estado. Pude ver que esto es útil si se trata de mantener valores de instancia con estado que son costosos de determinar para que puedan ser reutilizados en solicitudes posteriores.

Este problema me ha estado preocupando por algún tiempo con suerte esta información ayuda a alguien.