Perdre L'État De Session

J'ai un ASP.net application où les Utilisateurs ne sont pas en mesure de mener à bien certaines actions, pour des raisons qui, je suppose, ne peut être lié à la perte de leur session (qui est l'endroit où je maintenir leur niveau actuel de l'utilisateur de l'information, et la façon de déterminer s'ils sont connectés)

Je suis à une perte de savoir pourquoi ils perdraient leur session, donc, ma première question est:

Ce qui (en général) serait la cause d'une perte de leur session, en ASP.net?

et depuis je ne sais pas quand un utilisateur perd sa session et ne peut pas reproduire moi-même:

Comment puis-je suivre quand j'ai de l'utilisateur perd sa session

Ci-dessous est mon sessionState config de référence

<sessionState
           mode="InProc"
           cookieless="false"
           cookieName="My.Site.Com"
           timeout="480"/>
  • Vous pourriez penser trop dur. Vous avez dit que vous êtes "supposer" que la session est perdue. Il est possible que ce soit une oie sauvage chasse. Peut-être vous pourriez être mieux de l'analyse de l'exception que vous êtes la réception et le prendre en compte. D'autres possibilités incluent des problèmes avec l'utilisation d'une batterie de serveurs web ou de cluster. Depuis le mode de session est "InProc", si les connexions changement de serveurs sur vous, l'état de la session sera perdu.
  • Je sais que je ne suis pas à l'aide d'une batterie de serveurs web pour sûr que je suis sur une machine virtuelle si. Je suis, certes, uniquement dans l'hypothèse, mais je suis sur à 80% que c'est l'état de session, et à tout le moins, je voudrais continuer à les assumer son d'un problème jusqu'à ce que je peut l'exclure.
  • Pour moi, il a travaillé pour ajouter une machine clé de mon web.config. Je l'ai héberger sur un hébergement mutualisé et ce lien d'aider à la création d'un local et de les publier. lien
InformationsquelleAutor Adam Ritenauer | 2010-08-18
  1. 103

    Un certain nombre de choses peuvent provoquer l'état de session disparaissent mystérieusement.

    1. Votre sessionState délai d'attente a expiré
    2. Vous mettez à jour votre site web.config ou autre type de fichier que les causes de votre domaine d'application de recycler
    3. Votre pool d'applications IIS recycle
    4. Vous mettez à jour votre site avec un grand nombre de fichiers, et ASP.NET de manière proactive détruit votre domaine d'application de rassembler et de préserver la mémoire.

    -

    Si vous utilisez IIS 7 ou 7.5, voici quelques choses à rechercher:

    1. Par défaut, IIS jeux de AppPools à tourner sur elles-mêmes après une période d'inactivité.
    2. Par défaut, IIS jeux de AppPools de recycler chaque 1740 minutes (évidemment en fonction de votre configuration de la racine, mais que c'est la valeur par défaut)
    3. Dans IIS, consultez la rubrique "Paramètres Avancés" de votre pool d'applications. C'est une propriété appelée "délai d'Inactivité". Set à zéro ou à un nombre plus élevé que la valeur par défaut (20).
    4. Dans IIS, consultez le "Recyclage" des paramètres de votre pool d'applications. Ici, vous pouvez activer ou désactiver votre pool d'applications de recyclage. La 2ème page de l'assistant est une sorte de journal dans le Journal des Événements de chaque type de pool d'applications de l'arrêter.

    Si vous utilisez IIS 6, les mêmes paramètres s'appliquent (pour la plupart, mais avec des moyens différents d'arriver à eux), mais de les amener à se connecter le recycle est plus d'une douleur. Voici un lien vers un moyen d'obtenir IIS 6 au journal du pool d'applications de recycler les événements:

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

    -

    Si vous êtes à la mise à jour de fichiers sur votre application web, vous devriez vous attendre de toutes les sessions d'être perdu. C'est juste la nature de la bête. Toutefois, vous ne pourriez pas attendre que ça arrive plusieurs fois. Si vous mettez à jour 15 fichiers ou plus (aspx, dll, etc), il ya une probabilité que vous aurez de multiples redémarrages sur une période de temps, car ces pages sont recompilés par les utilisateurs accédant 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

    Réglage de la numCompilesBeforeAppRestart à un nombre plus élevé (ou manuellement rebondir votre pool d'applications), permettra d'éliminer ce problème.

    -

    Vous pouvez toujours gérer Application_SessionStart et Application_SessionEnd pour être averti lorsqu'une session est créée ou terminé. Le HttpSessionState classe possède également un IsNewSession de la propriété vous pouvez le vérifier sur n'importe quelle page de demande afin de déterminer si une nouvelle session est créée pour l'utilisateur actif.

    -

    Enfin, si c'est possible dans votre cas, j'ai utilisé le Mode de session SQL Server avec un bon succès. Il n'est pas recommandé si vous envisagez de stocker une grande quantité de données (chaque demande de charge et enregistre la quantité totale de données à partir de SQL Server) et il peut être une douleur si vous mettez des objets personnalisés (comme ils doivent être sérialisables), mais il m'a aidé dans le cas d'un hébergement mutualisé scénario où je n'arrivais pas à configurer mon pool d'applications pour ne pas recycler quelques heures. Dans mon cas, j'ai stocké des informations limitées et il a eu aucun effet néfaste sur la performance de l'effet. Ajoutez à cela le fait qu'un utilisateur existant de réutilisation de leurs id de session par défaut et mes utilisateurs ne jamais remarqué le fait que leur Session en mémoire a été abandonné par un pool d'applications recycler parce que tout leur état a été stockée dans SQL Server.

    • Wow... tout à fait une liste exhaustive, je vous remercie! Vous répertoriées de tout ce qui pourrait se produire sur le côté serveur, est-il quelque chose qui pourrait se produire, ce qui entraverait la capacité d'IIS pour en identifier la demande et de la correspondance avec les propper session?
    • Oui mais ils sont beaucoup moins susceptibles. Quelqu'un d'autre, mentionné ici, une procuration peut être bousiller le cookie de session, bien que tout le moderne proxy ne risquaient pas de le faire (parce que tous les web dev environnements d'utilisation des cookies de session). J'ai connu ça récemment sur une seule application web, un couple de fois - d'abord il a été AppPool recycle, alors c'est la page des mises à jour (causée par > 15 pages dans une mise à jour).
    • Comment je peux configurer IIS sur le serveur (pas mon pc local)?
    • Tout a été de travailler sur une ancienne asp.net application et c'est le "20 minutes par défaut".
    • Même courant IIS par défaut est 20 minutes. @JonH
    • Je pensais vraiment que je l'ai résolu, mais apparemment pas. Mon problème est encore plus étrange. Les valeurs dans mon formulaire disparaissent après environ 20 minutes d'inactivité. L'état de session n'est pas perdu...mais si dans le code derrière je fais quelque chose comme string text = MyDropDownlist.SelectedValue; la liste déroulante est vide ou nulle. Cela arrive à tout asp.net de contrôle. J'ai déjà vérifié le paramètre avancé de l'application de la piscine et l'a modifié à 60 minutes juste pour un test de cohérence. Je ne sais pas quoi regarder ou même de quoi google...
    • Astuce: IsNewSession restera vrai jusqu'à ce que vous ajouter quelque chose dans la session. Le simple fait de mentionner ce parce que c'est un méchant bug de supposer qu'il signifie IsFirstRequest - dont il n'a pas.

    InformationsquelleAutor Adam Sills
  2. 2

    J'ai eu une situation dans ASP.NET 4.0 où ma session se réinitialiser à chaque demande de page (et mon SESSION_START code exécuté sur chaque demande de page). Ce n'est pas arrivé à chaque utilisateur pour chaque session, mais en général cela s'est passé, et quand il l'a fait, qu'il allait se passer sur chaque demande de page.

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

    cookieless="false"

    Quand je l'ai changé pour la suite...

    cookieless="UseCookies"

    ... le problème semblait s'en aller. Apparemment, vrai|faux sont d'anciennes choix de ASP.NET 1. Départ en ASP.Net 2.0, énumérés choix ont commencé à être disponibles. Je suppose que ces options sont déconseillées. La "fausse" la valeur n'a jamais posé un problème dans le passé - je ne l'ai remarqué sur ASP.NET 4.0. Je ne sais pas si quelque chose a changé dans la version 4.0 qui ne prend plus en charge correctement.

    Aussi, je viens de trouver ceci n'ya pas longtemps. Puisque le problème est intermittent avant, je suppose que je pourrais tout de même de le rencontrer, mais jusqu'à présent, c'est de travailler avec ce nouveau paramètre.

    InformationsquelleAutor Rick
  3. 2

    Dans mon cas, paramètre de pool d'applications->AdvancedSettings->Maximum Travailleur Proccesses de 1 a aidé.

    • Grand. - il m'aider à résoudre le problème.
    • vous êtes l'homme!!! elle fonctionne.
    InformationsquelleAutor Michael
  4. 1

    Votre session est perdu becoz....

    J'ai trouvé un scénario où la session est perdue - Dans un asp.net page, pour un montant champ de zone de texte contient des caractères non valides, et suivie par une variable de session de récupération pour d'autres fins.Après avoir affiché le numéro invalide l'analyse par le biais de Convertir.ToInt32 ou double soulève une exception de première chance, mais l'erreur de ne pas montrer à cette ligne, au Lieu de cela, Séance annulée en raison d'une exception non gérée, d'erreur s'affiche lors de la session de récupération, ainsi tromper le débogage...

    CONSEIL: Testez votre système à l'échec c' - DESTRUCTRICE.. entrez la jonque assez indépendants des scénarios pour ex: après les résultats de la recherche affichés entrer indésirable dans les critères de recherche et goto détails des résultats de recherche... , vous serez en mesure de reproduire cette machine sur votre base de code de trop...:)

    Espérons que cela Aide, hydtechie

    • +1 .Très intéressante. Nous avons eu exactement le même problème. Une erreur non gérée lors de l'écriture dans un fichier texte causé à la session d'obtenir anéanti! Dans l'écriture de texte fichier de module, il n'y a pas de code pour toucher la séance!
    • Pourriez vous s'il vous plaît upvote comme c'est l'été poussé vers le bas par les aveugles, les autorités..C'est une vraie expérience...!
    InformationsquelleAutor HydTechie
  5. 0

    Vous pourriez ajouter un peu de journalisation pour le Mondial.asax dans la fonction Session_Start et Application_Start de suivre ce qu'il se passe avec la Session de l'utilisateur et de l'Application dans son ensemble.

    Aussi, méfiez-vous de vous êtes en cours d'exécution dans la Batterie de serveurs Web (mode de multiples IIS fils défini dans l'application de la piscine) ou d'équilibrage de la charge, car l'utilisateur peut finir par frapper un autre serveur qui n'a pas la même mémoire. Si c'est le cas, vous pouvez basculer le mode de Session SQL Server.

    • Batterie de serveurs Web ne serait pas plusieurs processus de travail pour l'application de la piscine. Que serait un Jardin Web. Une batterie de serveurs web s'est étendue sur plusieurs serveurs.
    InformationsquelleAutor Jemes
  6. 0

    Je ne faisais que perdre la séance qui n'était pas une chaîne ou un entier, mais un datarow.
    Mettre les données dans un objet sérialisable et d'économie que pour la session en cours a fonctionné pour moi.

    InformationsquelleAutor Gert R.
  7. 0

    Eu un problème sur IIS 8 lors de la récupération du Contenu via Ajax. Le problème est que les MaximumWorkerProcesses a été mis à 2 et Javascript inauguré le 17 demandes simultanées. C'est plus que le pool d'applications pourrait poignée et une nouvelle piscine (sans auth-données) a été ouvert.

    Solution a été de Changer MaximumWorkerProcesses à 0 dans IIS -> Server -> Application Pools -> [myPool] -> Advanced Settings -> Process Model -> MaximumWorkerProcesses.

    InformationsquelleAutor Martin Seitl
  8. 0

    Ne sais pas est-il lié à votre problème ou pas, MAIS Windows Server 2008 R2 service pack 2 a modifié ses paramètres IIS, ce qui conduit à émettre à la persistance de session. Par défaut, il gère séparé variable de session pour HTTP et HTTPS. Lorsque les variables sont définies dans le protocole HTTPS, ces derniers seront disponibles uniquement sur les pages HTTPS lorsqu'elle passe.

    Pour résoudre le problème, il n'y a paramètre IIS. Dans le Gestionnaire des services IIS, ouvrez les propriétés ASP, développez Propriétés de Session, et de modifier
    Nouvelle ID de Connexion Sécurisée à Faux.

    InformationsquelleAutor SRK - Khurram