Perte de l'état de la session

Question

J'ai une application ASP.net dans laquelle les utilisateurs ne sont pas en mesure de mener à bien certaines actions, pour des raisons qui, je le suppose, ne peuvent être liées qu'à la perte de leur session (qui est l'endroit où je maintiens leurs informations d'utilisateur actuelles, et comment déterminer s'ils sont connectés).

Je n'arrive pas à comprendre pourquoi ils ont perdu leur session, alors ma première question est la suivante :

Qu'est-ce qui peut provoquer (en général) la perte de la session d'un utilisateur en ASP.net ?

et puisque je ne sais pas quand un utilisateur perd sa session et que je ne peux pas le reproduire moi-même :

Comment puis-je savoir quand un utilisateur perd sa session ?

Voici ma configuration de sessionState pour référence

<sessionState
           mode="InProc"
           cookieless="false"
           cookieName="My.Site.Com"
           timeout="480"/>

Answer 1

Un certain nombre de choses peuvent entraîner la disparition mystérieuse de l'état de la session.

1. Le délai de votre sessionState a expiré
2. Vous mettez à jour votre web.config ou autre type de fichier qui provoque le recyclage de votre AppDomain
3. Votre AppPool dans IIS recycle
4. Vous mettez à jour votre site avec beaucoup de fichiers, et ASP.NET détruit proactivement votre AppDomain pour recompiler et préserver la mémoire.

-

Si vous utilisez IIS 7 ou 7.5, voici quelques éléments à vérifier :

1. Par défaut, IIS configure les AppPools pour qu'ils se désactivent après une période d'inactivité.
2. Par défaut, IIS configure les AppPools pour qu'ils se recyclent toutes les 1740 minutes (cela dépend évidemment de votre configuration Root, mais c'est la valeur par défaut).
3. Dans IIS, vérifiez les "Paramètres avancés" de votre AppPool. Il y a une propriété appelée "Idle Time-out". Définissez-la à zéro ou à un nombre plus élevé que la valeur par défaut (20).
4. Dans IIS, vérifiez les paramètres de "Recyclage" de votre AppPool. Ici vous pouvez activer ou désactiver le recyclage de votre AppPool. La deuxième page de l'assistant est un moyen de consigner dans le journal des événements chaque type d'arrêt de l'AppPool.

Si vous utilisez IIS 6, les mêmes paramètres s'appliquent (pour la plupart, mais avec des moyens différents d'y accéder), mais il est plus difficile de les amener à enregistrer les recyclages. Voici un lien vers une méthode permettant à IIS 6 d'enregistrer les événements de recyclage d'AppPool :

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

-

Si vous mettez à jour des fichiers sur votre application web, vous devez vous attendre à ce que toutes les sessions soient perdues. C'est la nature même de la bête. Cependant, vous ne devez pas vous attendre à ce que cela se produise plusieurs fois. Si vous mettez à jour 15 fichiers ou plus (aspx, dll, etc.), il est probable que vous aurez de multiples redémarrages sur une période donnée, car ces pages sont recompilées par les utilisateurs qui accèdent au site. Voir ces deux liens :

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

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

En fixant le numCompilesBeforeAppRestart à un nombre plus élevé (ou en faisant rebondir manuellement votre AppPool), vous éliminerez ce problème.

-

Vous pouvez toujours gérer Application_SessionStart et Application_SessionEnd pour être informé de la création ou de la fin d'une session. La classe HttpSessionState possède également une classe IsNewSession que vous pouvez vérifier à chaque demande de page pour déterminer si une nouvelle session est créée pour l'utilisateur actif.

-

Enfin, si c'est possible dans votre cas, j'ai utilisé l'outil d'évaluation de la qualité de l'eau. Mode de session du serveur SQL avec un bon succès. Ce n'est pas recommandé si vous y stockez une grande quantité de données (chaque requête charge et sauvegarde la totalité des données du serveur SQL) et cela peut être pénible si vous y placez des objets personnalisés (car ils doivent être sérialisables), mais cela m'a aidé dans un scénario d'hébergement partagé où je ne pouvais pas configurer mon AppPool pour ne pas recycler quelques heures. Dans mon cas, j'ai stocké des informations limitées et cela n'a eu aucun effet négatif sur les performances. Ajoutez à cela le fait qu'un utilisateur existant réutilisera son SessionID par défaut et mes utilisateurs n'ont jamais remarqué que leur session en mémoire avait été abandonnée par un recyclage AppPool parce que tout leur état était stocké dans le serveur SQL.

Answer 2

J'avais une situation dans ASP.NET 4.0 où ma session était réinitialisée à chaque demande de page (et mon code SESSION_START était exécuté à chaque demande de page). Cela n'arrivait pas à tous les utilisateurs et à toutes les sessions, mais c'était généralement le cas, et lorsque c'était le cas, c'était à chaque demande de page.

Ma balise web.config sessionState avait le même paramètre que celui mentionné ci-dessus.

cookieless="false"

Quand je l'ai changé en ce qui suit...

cookieless="UseCookies"

... le problème a semblé disparaître. Apparemment, true|false étaient de vieux choix datant de ASP.NET 1. À partir d'ASP.Net 2.0, les choix énumérés ont commencé à être disponibles. Je suppose que ces options ont été dépréciées. La valeur "false" n'a jamais posé de problème dans le passé - je ne l'ai remarqué que dans ASP.NET 4.0. Je ne sais pas si quelque chose a changé dans la version 4.0 qui ne la prend plus en charge correctement.

De plus, je viens de découvrir ça il n'y a pas longtemps. Comme le problème était intermittent auparavant, je suppose que je pourrais encore le rencontrer, mais jusqu'à présent, il fonctionne avec ce nouveau paramètre.

Answer 3

Votre session est perdue parce queoz....

J'ai trouvé un scénario où la session est perdue - Dans une page asp.net, pour un champ de zone de texte de montant a des caractères invalides, et suivie par une récupération de variable de session pour un autre but.Après l'affichage du nombre invalide parsing par Convert.ToInt32 ou double soulève une exception de première chance, mais l'erreur ne montre pas à cette ligne, Au lieu de cela, la session étant nulle en raison de l'exception non gérée, montre l'erreur à la récupération de session, trompant ainsi le débogage ...

CONSEIL : Testez votre système pour le faire échouer - DESTRUCTIF... entrez suffisamment de déchets dans des scénarios sans rapport, par exemple : après l'affichage des résultats de recherche, entrez des déchets dans les critères de recherche et allez dans les détails du résultat de la recherche... Vous serez en mesure de reproduire cette machine sur votre base de code locale aussi... :)

J'espère que cela vous aidera, hydtechie

Answer 4

Dans mon cas, le réglage de AppPool->AdvancedSettings->Maximum Worker Proccesses à 1 a aidé.

Answer 5

Vous pouvez ajouter des journaux à Global.asax dans Session_Start et Application_Start pour suivre ce qui se passe dans la session de l'utilisateur et l'application dans son ensemble.

Faites également attention si vous utilisez le mode Web Farm (plusieurs threads IIS définis dans le pool d'applications) ou l'équilibrage de charge, car l'utilisateur peut se retrouver sur un autre serveur qui ne dispose pas de la même mémoire. Si c'est le cas, vous pouvez basculer le mode Session sur SQL Server.