session-state

Ich dachte, ich würde ein (längst überfälliges) Update veröffentlichen - es war definitiv die gespeicherte Prozedur, die das Problem am Ende verursacht, wie in meinem Update oben. Wenn Sie die gleichen Probleme haben, schlage ich vor, es komplett zu deaktivieren - aber es hat den Trick für uns gemacht.

Ich habe ein wirklich, wirklich seltsames Problem, von dem ich hoffe, dass jemand etwas Licht darauf werfen kann. Wir haben eine Form, die uns Probleme verursacht hat, und durch Debugging usw. wurde festgestellt, dass dies auf eine Session-Variable zurückzuführen war, die "zufällig" verschwand.

Wir wissen, dass es kein Code ist - um das zu eliminieren, haben wir eine wirklich einfache Form mit einem Buchstaben und einem Knopf geklopft. Wenn es sich beim Laden der Seite nicht um ein Postback handelt, legt es eine Sitzungsvariable fest, sagen Sie "myvalue" mit dem Datum und der Uhrzeit. Wenn der Benutzer auf die Schaltfläche klickt, wird die Sitzung für diese Variable überprüft und anschließend angezeigt, ob sie vorhanden war oder nicht. Es wird dann die Sitzung verlassen, damit die nächsten Läufe gelöscht werden (dies geschieht nicht in der oben beschriebenen Form - das ist nur zum Testen).

Allerdings werden 90 von 100 Fällen (um der Argumente willen) so gehandhabt, wie Sie es erwarten würden. Aber für diese 10, verstreut über den Test nach dem Zufallsprinzip - also keine bestimmten Zeitspannen oder Testwiederholungen - wird es berichten, dass die Variable verschwunden ist.

Jetzt habe ich bestätigt, dass dies zu 100% der Fall ist, weil die Sitzung sich in völlig zufälligen Intervallen neu startet. Beim ersten Laden der Seite gibt es an, dass IsNewSession true ist - was ich beim ersten Mal erwarten würde. Beim Postback ist es auf IsNewSession = false gesetzt - wieder, was ich erwarten würde, und meine Variable zu booten ist in Ort.

Wenn es jedoch schief geht, ist die erste Anfrage IsNewSession wahr, aber beim Postback wird sie wieder auf "True" gesetzt - ohne Variablen im Speicher.

Die Umgebung verwendet die AspState-Datenbank (SQL Server). Es gibt nichts Offensichtliches - und was noch schlimmer ist, ist die zufällige Natur des Problems. Timeouts sind praktisch eliminiert. Der einzige Unterschied besteht darin, dass sich diese in einer LOAD BALANCED-Umgebung auf 4 Servern befindet. Wir haben die Anwendungs-ID in IIS (7.5) überprüft und sie sind alle gleich - gleiche Maschinenschlüssel usw.

Hat jemand eine Idee, was hier vor sich geht? Es ist .Net 2 BTW, das könnte das Problem sein - Ich hoffe, es ist ein bekanntes Problem mit der Versionsverwaltung dieser Versionen, aber bis jetzt kann ich nichts finden, das die Ursache zeigen könnte.

Das Problem scheint nicht angezeigt zu werden, wenn InProc auf einem Server verwendet wird. Es scheint nur mit Sql Server zu passieren.

Vielen Dank im Voraus - wirklich jede Hilfe zu schätzen,

Prost, Tony

Aktualisierung:

Wir denken, wir haben das Problem gelöst. Die gespeicherte Prozedur DeleteExpiredSessions wird jede Minute ausgeführt. Dies ist die angepasste Version, die Microsoft in ihrem KB-Artikel Ссылка empfohlen hat. Dies wurde jede Minute live ausgeführt - also haben wir dies im Test repliziert (was auch Last ausgeglichen ist) und den Job so eingerichtet, dass er im selben Intervall läuft.

Das Gleiche ist im Test passiert. Indem Sie dies im Live deaktivieren, ist das Problem jetzt verschwunden.

Offensichtlich blockiert es entweder (was wir in den Protokollen oder dem Aktivitätsmonitor nicht sehen können) oder entfernt noch gültige Sitzungen.

Hat das schon mal jemand gesehen? Meine aktuelle Theorie ist, dass die Sitzung bei jedem Aufruf des Servers, auf dem Sie landen, initialisiert wird, aber dann bei der Postback-Umleitung zu einem anderen Server, aus welchem ​​Grund auch immer, wird die Sitzung als "ungültig" betrachtet und wiederverwendet.