Perdere stato di sessione

Ho un’applicazione ASP.net in cui gli utenti non sono in grado di completare con successo determinate azioni, per ragioni, presumo, possono essere solo correlate alla perdita della loro sessione (che è dove mantengo le loro attuali informazioni utente e come determinare se sono loggati)

Sono in perdita sul motivo per cui avrebbero perso la loro sessione, quindi la mia prima domanda è:

Cosa (in generale) causerebbe la perdita della sessione in ASP.net da parte di un utente?

e poiché non so quando un utente perde la sessione e non può riprodurlo da solo:

Come posso rintracciare quando l’utente perde la sessione

Di seguito è riportata la mia configurazione di sessione per riferimento

 

Un certo numero di cose può far scomparire misteriosamente lo stato della sessione.

  1. Il timeout della sessioneStato è scaduto
  2. Aggiorna il tuo web.config o altro tipo di file che causa il riciclo di AppDomain
  3. Il tuo AppPool in IIS ricicla
  4. Aggiorna il tuo sito con molti file e ASP.NET distrugge in modo proattivo il tuo AppDomain per ricompilare e conservare la memoria.

Se stai usando IIS 7 o 7.5, ecco alcune cose da cercare:

  1. Per impostazione predefinita, IIS imposta AppPools per distriggersrsi dopo un periodo di inattività.
  2. Per impostazione predefinita, IIS imposta AppPools per il riciclo ogni 1740 minuti (ovviamente a seconda della configurazione di root, ma questa è l’impostazione predefinita)
  3. In IIS, controlla le “Impostazioni avanzate” del tuo AppPool. In c’è una proprietà chiamata “Idle Time-out”. Impostalo su zero o su un numero superiore a quello predefinito (20).
  4. In IIS, controlla le impostazioni “Riciclaggio” del tuo AppPool. Qui puoi abilitare o disabilitare il tuo AppPool dal riciclaggio. La seconda pagina della procedura guidata è un modo per accedere al registro eventi distriggersto da ciascun tipo di AppPool.

Se si utilizza IIS 6, si applicano le stesse impostazioni (per la maggior parte ma con modalità diverse per raggiungerle), tuttavia far sì che registrino i ricicli è più doloroso. Ecco un collegamento a un modo per ottenere IIS 6 per il log degli eventi di riciclo AppPool:

http://web.archive.org/web/20100803114054/http://surrealization.com/sample-code/getnotifiedwhenapppoolrecycles/

Se stai aggiornando i file sulla tua app Web, dovresti aspettarti che tutte le sessioni vadano perse. Questa è solo la natura della bestia. Tuttavia, potresti non aspettarti che accada più volte. Se si aggiornano 15 o più file (aspx, dll, ecc.), È probabile che si avvieranno più riavvii per un periodo di tempo poiché queste pagine vengono ricompilate dagli utenti che accedono al sito. Vedi questi due link:

http://support.microsoft.com/kb/319947

http://msdn.microsoft.com/en-us/library/system.web.configuration.compilationsection.numrecompilesbeforeapprestart.aspx

Impostando numCompilesBeforeAppRestart su un numero più alto (o rimbalzando manualmente il tuo AppPool) si eliminerà questo problema.

È sempre ansible gestire Application_SessionStart e Application_SessionEnd per essere avvisati quando una sessione viene creata o terminata. La class HttpSessionState dispone inoltre di una proprietà IsNewSession che è ansible controllare su qualsiasi richiesta di pagina per determinare se viene creata una nuova sessione per l’utente attivo.

Infine, se è ansible nel tuo caso, ho usato la modalità sessione di SQL Server con un buon successo. Non è consigliabile se si sta memorizzando una grande quantità di dati (ogni richiesta carica e salva l’intera quantità di dati da SQL Server) e può essere un problema se si inseriscono oggetti personalizzati (come devono essere serializzabili ), ma mi ha aiutato in uno scenario di hosting condiviso in cui non potevo configurare il mio AppPool per non riciclare un paio d’ore. Nel mio caso, ho memorizzato informazioni limitate e non ha avuto alcun effetto negativo sulle prestazioni. Aggiungete a ciò il fatto che un utente esistente riutilizzerà il proprio SessionID per impostazione predefinita e i miei utenti non hanno mai notato il fatto che la loro sessione in memoria è stata rilasciata da un riciclo AppPool perché tutto il loro stato era memorizzato in SQL Server.

Avevo una situazione in ASP.NET 4.0 in cui la mia sessione sarebbe stata ripristinata su ogni richiesta di pagina (e il mio codice SESSION_START sarebbe stato eseguito su ogni richiesta di pagina). Questo non è accaduto a tutti gli utenti per ogni sessione, ma di solito è successo, e quando ciò accadeva accadrebbe su ogni richiesta di pagina.

Il mio tag web.config sessionState aveva le stesse impostazioni di quello menzionato sopra.

 cookieless="false" 

Quando l’ho cambiato al seguente …

 cookieless="UseCookies" 

… il problema sembrava andare via. Apparentemente true | false erano vecchie scelte da ASP.NET 1. A partire da ASP.Net 2.0, le scelte enumerate iniziarono ad essere disponibili. Immagino che queste opzioni fossero deprecate. Il valore “falso” non ha mai presentato un problema in passato – ho notato solo su ASP.NET 4.0. Non so se qualcosa è cambiato in 4.0 che non lo supporta più correttamente.

Inoltre, l’ho appena scoperto non molto tempo fa. Poiché il problema era intermittente prima, suppongo che potrei comunque incontrarlo, ma finora funziona con questa nuova impostazione.

La tua sessione è persa perché …

Ho trovato uno scenario in cui la sessione è persa – In una pagina asp.net, per un campo di testo di una quantità sono presenti caratteri non validi e seguito da un recupero di variabili di sessione per altri scopi.Dopo aver pubblicato l’analisi del numero non valido tramite Convert.ToInt32 o doppio solleva una prima eccezione, ma l’errore non viene visualizzato su quella riga, invece di quello, Session è nullo a causa di un’eccezione non gestita, mostra un errore durante il recupero della sessione, ingannando così il debugging …

SUGGERIMENTO: prova il tuo sistema per fallirlo- DISTRUTTIVO .. inserisci abbastanza cianfrusaglie in scenari non correlati per es: dopo che i risultati della ricerca mostrati entrano nella spazzatura nei criteri di ricerca e vai a dettagli dei risultati della ricerca …, sarai in grado di riprodurre questa macchina sul tuo codice base locale troppo … 🙂

Spero che aiuti, Hydtechie

Nel mio caso, l’impostazione AppPool-> AdvancedSettings-> Maximum Worker Proccesses su 1 è stata utile.

È ansible aggiungere alcune registrazioni a Global.asax in Session_Start e Application_Start per tenere traccia di ciò che accade nella sessione dell’utente e nell’applicazione nel suo complesso.

Inoltre, fai attenzione a quando esegui la modalità Web Farm (più thread IIS definiti nel pool di applicazioni) o esegui il bilanciamento del carico perché l’utente può finire per colpire un server diverso che non ha la stessa memoria. In tal caso, è ansible passare dalla modalità sessione a SQL Server.

Stavo solo perdendo la sessione che non era una stringa o un intero, ma un datarow. Mettere i dati in un object serializzabile e salvarlo nella sessione ha funzionato per me.

Ha avuto un problema su IIS 8 durante il recupero di contenuti tramite Ajax. Il problema era che MaximumWorkerProcesses era impostato su 2 e Javascript ha aperto 17 richieste simultanee. Era più di quanto l’AppPool potesse gestire e fu aperto un nuovo pool (senza auth-data).

La soluzione era di modificare MaximumWorkerProcesses su 0 in IIS -> Server -> Application Pools -> [myPool] -> Advanced Settings -> Process Model -> MaximumWorkerProcesses .