Un utente asp.net può effettuare più di una richiesta alla volta se la Sessione è in uso?

Question

Non riesco a effettuare più di una richiesta alla volta in asp.net mentre la sessione è attiva. Perché esiste questa limitazione? C'è un modo per aggirarlo?

Questo problema può essere dimostrato con un'app WebForms con solo 3 pagine aspx semplici (anche se la limitazione si applica ancora in asp.net mvc).

Creare un'applicazione web asp.net 3.5.

Non ci dovrebbero essere solo tre pagine: NoWait.aspx, Wait.aspx, e SessionStart.aspx

NoWait.aspx ha questo unico pepita aggiunto tra i tag div di default: <% = DateTime.Now.Ticks %>. Il code-behind per questa pagina è il predefinito (vuoto).

Wait.aspx è simile a NoWait.aspx, ma ha una riga aggiunta a Page_Load nel code-behind: Thread.Sleep (3000); // wait 3 seconds

SessionStart.aspx ha anche l'aspetto di NoWait.aspx, ma ha questa singola riga nel suo code-behind: Session ["Whatever"] = "Anything";

Aprire un browser e andare a NoWait.aspx. Mostra correttamente un numero nella risposta, ad esempio: "633937963004391610". Continua a rinfrescare e continua a cambiare il numero. Ottimo finora! Crea una nuova scheda nello stesso browser e vai su Wait.aspx. Si siede per 3 secondi, quindi scrive il numero nella risposta. Ottimo finora! No, prova questo: vai su Wait.aspx e mentre gira, passa rapidamente a NoWait.aspx e aggiorna. Anche mentre Wait.aspx sta dormendo, NoWait.aspx fornirà una risposta. Ottimo finora. È possibile continuare ad aggiornare NoWait.aspx mentre Wait.aspx è in rotazione e il server invia ogni volta una risposta. Questo è il comportamento che mi aspetto.

Ora è dove diventa strano.

In una terza scheda, nello stesso browser, visitare SessionStart.aspx. Quindi, passare a Wait.aspx e aggiornare. Mentre gira, passa a NoWait.aspx e aggiorna. NoWait.aspx NON invierà una risposta fino a quando Wait.aspx non sarà in esecuzione!

Ciò dimostra che mentre una sessione è attiva, non è possibile effettuare richieste simultanee con lo stesso utente. Le richieste vengono tutte messe in coda e pubblicate in modo sincrono. Non mi aspetto o capisco questo comportamento. Ho testato questo sul server Web integrato di Visual Studio 2008 e anche su IIS 7 e IIS 7.5.

Così ho alcune domande:

1) Ho ragione che esiste effettivamente una limitazione qui, o è la mia prova di cui sopra non valida perché sto facendo qualcosa di sbagliato?

2) C'è un modo per ovviare a questa limitazione? Nella mia app web, alcune cose richiedono molto tempo per essere eseguite, e vorrei che gli utenti potessero fare cose in altre schede mentre aspettano una grande richiesta da completare. Posso in qualche modo configurare la sessione per consentire "letture sporche"? Questo potrebbe impedire che venga bloccato durante la richiesta?

3) Perché esiste questa limitazione? Vorrei ottenere una buona comprensione del motivo per cui questa limitazione è necessaria. Penso che sarei uno sviluppatore migliore se lo sapessi!

Answer 1

Here is a link talking about session state and locking. Esegue e blocco esclusivo.

Il modo più semplice per aggirare questo è rendere le attività a esecuzione prolungata in modo asincrono.È possibile eseguire le attività di esecuzione prolungata su un thread separato o utilizzare e asynchronous delegate e restituire immediatamente una risposta al browser. La pagina lato client può inviare richieste al server per controllare e vedere se è fatta (tramite ajax molto probabilmente), e quando il server dice al client che è finita, avvisare l'utente. In questo modo, anche se le richieste del server devono essere gestite una alla volta dal server, non è così per l'utente.

Questo ha il proprio set di problemi, e dovrete assicurarvi che l'account per il contesto HTTP che chiude come quello disporrà determinate funzionalità nella sessione di asp.net. Un esempio che probabilmente dovrai considerare è probabilmente il rilascio di un blocco sulla sessione, se ciò si verifica effettivamente.

Questo non è troppo sorprendente che questo potrebbe essere un limite. Ogni browser avrebbe la propria sessione, prima dell'avvento di ajax, le richieste post back erano sincrone. Fare lo stesso handle sessione simultanea potrebbe ottenere veramente brutto, e posso vedere come questo non sarebbe una priorità per i team di IIS e ASP.NET per aggiungere a.

Answer 2

Per motivi di Kevin descritto, gli utenti non possono accedere a due pagine che potrebbero scrivere nello stato della sessione allo stesso tempo - il framework stesso non può esercitare un controllo preciso sul blocco del session store, quindi deve bloccarlo per intere richieste.

Per aggirare il problema, le pagine che solo leggono i dati di sessione possono dichiarare che lo fanno. ASP.NET non otterrà un blocco di scrittura stato sessione per loro:

// Or false if it doesn't need access to session state at all 
EnableSessionState="ReadOnly"