le code: Le problème: quand foo.aspx lit "foo" de La session, ce n'est pas là. La session est là, mais il n'y a pas de valeur pour "foo". J'ai observé cette intermittence dans notre environnement de production. Mais je ne veux pas dire ici pour demander à une question sur Response.redirect () . Bertrand Le Roy explique (le audacieux est à moi): maintenant, quelle redirection est-elle d'envoyer un
en-tête spécial sur le client pour que
il demande au serveur un autre
page que celle qui attendait.
Côté serveur, après avoir envoyé ceci
En-tête, la redirection met fin à la réponse.
C'est une chose très violente à faire.
Réponse.end effectivement arrête le
exécution de la page où qu'il soit
en utilisant une exception threadabortex. Quoi
arrive vraiment ici est que le
Jeton de session se perd dans la bataille.
My Takeaway Il y a cette réponse.ReDirect () peut être gourmand avec des fils de fin. Et cela peut menacer ma session écrit s'ils se produisent trop près de cette hautesse. La question: Qu'en est-il de la gestion de la session ASP.NET le fait si vulnérable à cela? La ligne de code Response.redirect () ne commence pas son exécution tant que la ligne d'écriture de session est «terminée» - Comment peut-il être une telle menace pour ma session écrire? Qu'en est-il de l'écriture de la session Ne "finir" pas avant que la prochaine ligne de code s'exécute? Y a-t-il d'autres scénarios dans lesquels des écritures de session sont similaires (comme elles ne se sont jamais produites) perdues?
3 Réponses :
Je ne suis pas assez familier avec les internes de la session écrit, mais j'imagine que cela a des complexités, car elle s'appuie sur la traduction des cookies de session de navigateur dans une identification de serveur. De plus, ThreadabortExceptions ont des considérations spéciales dans le runtime, qui peut jouer ici, je ne suis pas sûr.
Dans tous les cas, réponse.redirect () code> a une surcharge qui prend un paramètre booléen qui vous permet de préciser si vous souhaitez mettre fin au fil ou non. P> Response.Redirect(string url, bool endResponse);
Le recyclage du pool d'applications peut faire disparaître votre session. Vous pouvez configurer le pool d'applications pour recycler à des moments fixes (recommandé et la nuit ou pendant les périodes d'utilisation basse) ou augmenter la période de délai d'expiration de votre recyclage de pool d'applications.
Après avoir testé plusieurs alternatives (réponse.redirect (..., false), serveur.Transfer () et d'autres "solutions" Je ne peux pas maintenant vous rappeler), nous avons trouvé une seule réponse fiable à ce problème.
Déplacement de notre état de session de InproC à SQLServer effectivement éradiqué ce comportement de nos systèmes, laissant la réponse.redirect (...) complètement fiable. Si d'autres tests montrent le contraire, je vais faire un rapport ici, mais je dis que, pour faire ce stop à se produire dans votre environnement: déplacez votre état de session en SQLServer (ou est «hors indproc» suffisant? Je ne suis pas sûr). < / p>