2010-07-23 24 views
6

Non è stato possibile trovare una risposta definitiva a questo, quando viene stabilita una sessione client su un'applicazione ASP.NET MVC2, presumo che una particolare discussione da un pool di thread gestisca tale richiesta. Lo stesso thread gestisce sempre tutte le richieste successive per quella sessione? Quindi, in teoria, se in qualche modo l'ID della sessione fosse incasinato e il thread sbagliato non fosse stato selezionato, allora mancavano tutti i dati a livello di sessione? GrazieSessione e thread

+0

Non sono sicuro di come l'aspetto della filettatura possa causare errori nell'ID della sessione. Puoi spiegare qualcosa di più? –

risposta

2

No. Ogni richiesta può essere gestita da una filettatura diversa. Ciò significa che varie risorse su una pagina possono essere gestite da thread diversi. Oppure potrebbero essere gestiti sullo stesso. Spetta al processo di lavoro ed è necessario stabilire se vale la pena creare un nuovo thread o meglio aspettare fino a quando uno diventa disponibile.

La pagina verrà renderizzata da un thread e quindi le immagini, i fogli di stile e i javascript possono essere gestiti sullo stesso o su altri thread. Questo è fondamentale per la natura senza stato ASP.NET e la programmazione web in generale. Ciò che ti permette di fare è di bilanciare il carico di tutte le tue richieste su server diversi o anche su domini diversi.

Questo ci porta alla tua domanda sullo stato della sessione. Non dovresti perdere gli ID di sessione tra le richieste. Se lo sei, qualcosa di serio è sbagliato. Oppure potresti trovarti in una situazione di Web farm/cluster in cui una richiesta viene inviata a un server e la successiva viene instradata a un'altra attraverso una sorta di bilanciamento del carico.

In uno scenario con bilanciamento del carico è necessario disporre di alcuni mezzi per mantenere lo stato della sessione. I due approcci più comuni sono il salvataggio in un database e in una cache distribuita. Il secondo è il mio approccio preferito perché i dati di sessione sono per loro natura una cosa temporanea e non appartengono a un db persistente.

3

In breve, no, non in IIS (non posso garantire per il server di sviluppo web "Cassini" in Visual Studio, ma dubito che anche lì)

È possibile dimostrare il filo cambiando aggiungendo il seguente a una visione:

<%= System.Threading.Thread.CurrentThread.ManagedThreadId %> 

Ora ripetutamente colpito la pagina dal vostro browser (o forse ha colpito da 2 o 3 browser) e vedrete che cambia di volta in volta.

Detto questo - in uno scenario semplice come questo, si può spesso vedere lo stesso filo servendo la richiesta come non vale la pena ASP.NET creare più thread di cui ha bisogno, ma una volta che si inizia a caricare il server , vedrai più thread.

Problemi correlati