Perdre l'état de session
J'ai une application ASP.net dans laquelle les utilisateurs ne sont pas en mesure d'effectuer certaines actions. Pour des raisons qui, je suppose, ne peuvent être liées qu'à la perte de leur session (c'est là que je conserve leurs informations d'utilisateur actuelles et comment déterminer si ils sont connectés)
Je ne comprends pas pourquoi ils perdraient leur session, alors ma première question est la suivante:
Qu'est-ce qui (en général) ferait perdre à l'utilisateur sa session en ASP.net?
et puisque je ne sais pas quand un utilisateur perd sa session et ne peut pas le reproduire moi-même:
Comment puis-je suivre quand mon utilisateur perd sa session
Ci-dessous ma config sessionState pour référence
<sessionState
mode="InProc"
cookieless="false"
cookieName="My.Site.Com"
timeout="480"/>
Un certain nombre de choses peuvent entraîner la disparition mystérieuse de l'état de la session.
- Votre délai d'expiration de session a expiré
- Vous mettez à jour votre fichier web.config ou un autre type de fichier qui entraîne le recyclage de votre AppDomain
- Votre AppPool dans IIS recycle
- Vous mettez à jour votre site avec beaucoup de fichiers et ASP.NET détruit de manière proactive votre AppDomain pour recompiler et conserver la mémoire.
-
Si vous utilisez IIS 7 ou 7.5, voici quelques points à rechercher:
- Par défaut, IIS définit AppPools pour s’éteindre après une période d’inactivité.
- Par défaut, IIS définit AppPools pour le recyclage toutes les 1740 minutes (évidemment selon votre configuration racine, mais c'est la valeur par défaut).
- Dans IIS, consultez les "Paramètres avancés" de votre AppPool. Il existe une propriété appelée "Délai d'inactivité". Définissez-le sur zéro ou sur un nombre supérieur à celui par défaut (20).
- Dans IIS, vérifiez les paramètres "Recyclage" de votre AppPool. Ici, vous pouvez activer ou désactiver votre AppPool du recyclage. La 2ème page de l'assistant est un moyen de se connecter au journal des événements chaque type d'AppPool arrêté.
Si vous utilisez IIS 6, les mêmes paramètres s'appliquent (dans la plupart des cas, mais avec des méthodes différentes pour les obtenir)). Cependant, les obliger à journaliser les recyclés est plus pénible. Voici: un lien vers un moyen d’obtenir IIS 6 pour consigner les événements de recyclage AppPool:
-
Si vous mettez à jour des fichiers sur votre application Web, vous devez vous attendre à ce que toutes les sessions soient perdues. C'est juste la nature de la bête. Cependant, vous ne pouvez 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 plusieurs redémarrages sur une période donnée, ces pages étant recompilées par les utilisateurs accédant au site. Voir ces deux liens:
http://support.Microsoft.com/kb/319947
Définir numCompilesBeforeAppRestart sur un nombre plus élevé (ou renvoyer manuellement votre AppPool) éliminera ce problème.
-
Vous pouvez toujours gérer Application_SessionStart et Application_SessionEnd pour être averti lorsqu'une session est créée ou terminée. La classe HttpSessionState a également une propriété IsNewSession que vous pouvez vérifier lors de toute demande de page pour déterminer si une nouvelle session est créée pour l'utilisateur actif.
-
Enfin, si cela est possible dans votre cas, j’ai utilisé le mode de session SQL Server avec succès. Cela n'est pas recommandé si vous stockez une grande quantité de données (chaque requête charge et enregistre la totalité des données de SQL Server) et cela peut être un problème si vous y insérez 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 qui n'ont eu aucun effet négatif sur les performances. Ajoutez à cela le fait qu'un utilisateur existant réutilise par défaut son SessionID et mes utilisateurs n'ont jamais remarqué le fait que leur session en mémoire a été abandonnée par un recyclage AppPool car tout leur état était stocké dans SQL Server.
Dans mon cas, configurer App Pool-> Paramètres avancés-> Nombre maximal de processus de travail à 1 aide.
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 s'exécutait à chaque demande de page). Cela n’arrivait pas à chaque utilisateur pour chaque session, mais c’était généralement le cas, et lorsque cela se produisait, cela se produisait à chaque demande de page.
Ma balise web.config sessionState avait le même paramètre que celui mentionné ci-dessus.
cookieless="false"
Quand j'ai changé pour le suivant ...
cookieless="UseCookies"
... le problème a semblé disparaître. Apparemment, true | false étaient d'anciens choix de ASP.NET 1. À partir de ASP.Net 2.0, les choix énumérés ont commencé à être disponibles. Je suppose que ces options ont été déconseillé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é en 4.0 qui ne le supporte plus correctement.
En outre, je viens de découvrir cela il n'y a pas longtemps. Comme le problème était intermittent auparavant, je suppose que je pourrais toujours le rencontrer, mais jusqu'à présent, cela fonctionne avec ce nouveau paramètre.
Votre session est perdue becoz ....
J'ai trouvé un scénario où la session est perdue - Dans une page asp.net, un champ de montant contient des caractères non valides, suivis d'une récupération de variable de session à une autre fin. Après publication du numéro non valide analysé via Convert.ToInt32 ou double déclenche une exception de première chance, mais l'erreur ne s'affiche pas sur cette ligne. Au lieu de cela, Session étant nulle en raison d'une exception non gérée, affiche une erreur lors de l'extraction de la session, trompant ainsi le débogage ...
ASTUCE: Testez votre système pour le mettre en échec - DESTRUCTIF .. entrez suffisamment de fichiers indésirables dans des scénarios différents, par exemple: après l'affichage des résultats de la recherche, entrez les fichiers indésirables dans les critères de recherche et obtenez les détails du résultat de la recherche ..., vous pourrez alors reproduire cet ordinateur sur votre ordinateur. code local aussi ... :)
J'espère que ça vous aidera, hydtechie
Je perdais seulement la session qui n'était pas une chaîne ou un entier mais un datarow. Mettre les données dans un objet sérialisable et les enregistrer dans la session a fonctionné pour moi.
Avait un problème sur IIS 8 lors de la récupération de contenu via Ajax. Le problème était que MaximumWorkerProcesses était défini sur 2 et Javascript ont ouvert 17 demandes simultanées. C'était plus que ce que l'AppPool pouvait gérer et un nouveau pool (sans authentification) a été ouvert.
La solution était de changer MaximumWorkerProcesses en 0 dans IIS -> Server -> Application Pools -> [myPool] -> Advanced Settings -> Process Model -> MaximumWorkerProcesses.
Je ne sais pas s'il est lié à votre problème ou non MAIS Windows 2008 Server R2 ou SP2 a modifié ses paramètres IIS, ce qui entraîne un problème de persistance de session. Par défaut, il gère une variable de session distincte pour HTTP et HTTPS Lorsque les variables sont définies dans HTTPS, elles ne sont disponibles que sur les pages HTTPS lorsqu’elles sont commutées.
Pour résoudre le problème, il existe un paramètre IIS. Dans IIS, ouvrez les propriétés ASP, développez - Propriétés de la session, et remplacez Nouvel ID sur la connexion sécurisée en False.
Vous pouvez ajouter une certaine journalisation à Global.asax dans Session_Start et Application_Start pour suivre ce qui se passe dans la session de l'utilisateur et dans l'ensemble de l'application.
Faites également attention à votre exécution en mode batterie de serveurs Web (plusieurs IIS définis dans le pool d'applications)) ou à un équilibrage de la charge, car l'utilisateur peut frapper un autre serveur sans le Si c'est le cas, vous pouvez passer du mode Session à SQL Server.