È HttpModule condiviso tra i thread di lavoro?

Question

Devo accesso alla serratura a membri di istanza?

Esempio:

public class HttpModule : IHttpModule
{
    //...

    Dictionary<int, int> foo;

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

Answer 1

Non è in cristallo chiaro per me così lontano dalla documentazione MSDN, ma ho trovato un post sul forum da parte di qualcuno che sostiene di conoscere la risposta . Sembra che non si deve aspettare roba cattiva per accadere con l'implementazione, ma si dovrebbe essere consapevoli del fatto che lo stato di foo non sarà necessariamente condiviso tra tutti i risultati dal tuo HttpModule viene creato quando per HttpApplication che IIS sceglie di mantenere nella sua piscina.

Answer 2

ho voluto offrire qui i miei risultati relativi a questa domanda, come ho osservato in IIS6:

Ho avuto a che fare con questo problema ampiamente in IIS6 e hanno trovato alcuni risultati interessanti utilizzando log4net e riflessione per cronologia di esecuzione di cattura. Quello che ho trovato è che non v'è ampia 'la gestione dei thread' che succede dietro le quinte. Sembra che vi sia una serie 'primario' di fili che corrisponde 1: 1 a HttpApplication. Questi fili però non si gestisce in esclusiva la pipeline per la vostra richiesta. Vari sotto-fili diversi possono essere chiamati quando questi casi sono accessibili. Successivamente nuove richieste e richieste di risorse utilizzate dall'applicazione sembrano condividere alcune informazioni persistenti relative alla vostra domanda originale, ma sono ancora mai gestito interamente dal thread iniziale che indica un certo tipo di rapporto. Non riuscivo a scorgere qualsiasi modello concreto (diverso da quello che ho descritto in precedenza) su quali elementi sono stati divvied ad altri thread come è stato apparentemente casuale. La mia conclusione a questa evidenza è che c'è qualche concetto di messa in comune gerarchica? che si verificano in cui alcuni sconosciuti sottoinsieme di elementi di riferimento sono ereditati nei fili del bambino attraverso il genitore di riferimento.

Così come una risposta direi che HttpModules sono condiviso tra i thread. In termini di bloccaggio valori di istanza, questo sarebbe applicabile se i valori valgono per tutte le richieste che utilizzano il modulo e devono mantenere uno stato. Ho potuto vedere questo essere utile se il tentativo di mantenere valori delle istanze con stato che sono costosi per accertare in modo che possano essere riutilizzati in successive richieste.

Questo problema era stato mi preoccupa da qualche tempo si spera che questo informazioni aiuta qualcuno.

Answer 3

Recentemente ho trovato un articolo che tocca questa domanda un po ': http://www.dominicpettifer.co.uk/Blog/41/ihttpmodule-gotchas---the-init---method-can-get-called-multiple-times

E non menziona le discussioni, ma dice solo che il processo di lavoro sarà

  

instantiate come molti HttpApplication   oggetti come si pensa di cui ha bisogno, allora   che sarà loro piscina per le prestazioni   ragioni, le istanze di riutilizzo come nuova   le richieste sono disponibili in prima di inviarli   di nuovo in piscina.

Dopo il codice dal link, si può essere sicuri che il codice di inizializzazione viene eseguito una volta in un modo thread-safe:

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

ho in mente di creare un'applicazione di test per eseguire questo e test di esso, solo per vedere se è vero, ma non ho avuto il tempo.

Answer 4

L'articolo pubblicato da Jim è interessante, ma come dice Jim non menziona nulla circa la sicurezza thread.

Credo che si avrebbe solo bisogno il meccanismo di blocco se si inizializza membri statici o l'esecuzione di "una sola volta" inizializzazioni vale a dire l'inizializzazione di una risorsa statica.

non ho potuto concludere da MSDN né l'articolo citato da Jim che abbiamo bisogno del meccanismo di blocco durante l'inizializzazione delle variabili di classe non statici.