É HttpModule compartilhadas entre threads de trabalho?

Question

Tenho para bloquear o acesso aos membros de instância?

Exemplo:

public class HttpModule : IHttpModule
{
    //...

    Dictionary<int, int> foo;

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

Answer 1

Não é claro para mim tão longe da documentação do MSDN, mas eu encontrei um Postagem do fórum de alguém que afirma saber a resposta. Parece que você não deveria esperar coisas ruins para acontecer com sua implementação, mas você deve estar ciente de que fooO estado não será necessariamente compartilhado em todos os resultados, pois o seu HttpModule será criado uma vez por HttpApplication que o IIS escolhe manter em sua piscina.

Answer 2

Eu queria oferecer aqui minhas descobertas relacionadas a esta pergunta, como observei no IIS6:

Eu tenho lidado com esse problema extensivamente no IIS6 e encontrei alguns resultados interessantes utilizando log4net e reflexão para capturar o histórico de execução. O que descobri é que existe um extenso 'gerenciamento de threads' nos bastidores. Parece que existe uma série de tópicos 'primários' que corresponde 1: 1 a HttpApplication. Esses tópicos, no entanto, para não lidar exclusivamente no pipeline para sua solicitação. Vários sub-threads diferentes posso ser chamado quando essas instâncias forem acessadas. Novas solicitações e solicitações de recursos subsequentes utilizados por seu aplicativo parecem compartilhar algumas informações persistentes relacionadas à sua solicitação original, mas ainda nunca foram tratadas inteiramente pelo encadeamento inicial indicando algum tipo de relacionamento. Não pude discernir nenhum padrão concreto (exceto o que descrevi anteriormente) sobre quais elementos foram divididos para outros fios, pois era aparentemente aleatório. Minha conclusão nessa evidência é que existe algum conceito de pool hierárquico? ocorrendo onde algum subconjunto desconhecido de elementos de referência é herdado nos threads infantis através da referência dos pais.

Então, como resposta, eu diria que HttpModules são compartilhado entre threads. Em termos de valores da instância de bloqueio, isso seria aplicável se os valores se aplicarem a todas as solicitações que usam o módulo e devem manter algum estado. Eu pude ver que isso é útil se tentar manter valores de instância com estado que são caros para verificar para que eles pudessem ser reutilizados nas solicitações subsequentes.

Esse problema estava me incomodando há algum tempo, espero que essa informação ajude alguém.

Answer 3

Recentemente, encontrei um artigo que aborda essa pergunta um pouco:http://www.dominicpettifer.co.uk/blog/41/ihttpmodule-gotchas---the-init---method-can-get-caled-multiple-times

Não menciona tópicos, mas apenas diz que o processo do trabalhador irá

Instanciar tantos objetos de httpplication quanto ele acha que precisa, então os reunirá por razões de desempenho, reutilizando instâncias à medida que novas solicitações chegam antes de enviá -las de volta ao pool.

Seguindo o código no link, você pode ter certeza de que seu código init é executado uma vez de maneira segura para threads:

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; 
            } 
        } 
    } 
}

Eu pretendo configurar um aplicativo de teste para executar isso e testá -lo, apenas para ver se é verdade, mas não tive tempo.

Answer 4

O artigo publicado por Jim é interessante, mas, como Jim diz que não mencionar nada sobre a segurança do thread.

Eu acho que você só precisa o mecanismo de bloqueio se você estiver inicializando membros estáticos ou a realização de "uma só vez" inicializações i.e.inicializando um recurso estático.

Eu não poderia concluir a partir do MSDN nem o artigo mencionado por Jim de que precisamos do mecanismo de bloqueio quando inicializar o não-static variáveis de classe.