Sitzung beschädigt mit aspnet_state Service

Question

Wir haben seit einiger Zeit Probleme mit Daten in unserer SQL-Datenbank gespeichert.

Manchmal werden Datensätze mit Daten gespeichert, die nicht mit dem Rest der Zeile übereinstimmen, sodass es so aussieht, als würden Daten für etwas anderes, vielleicht die Daten eines anderen Benutzers, ausgetauscht, bevor sie an die Datenbank übergeben werden .

Wir verwenden TransactionScopes durchgehend mit Isolationsstufe ReadCommitted, was mich glauben lässt, dass das Problem der Datenintegrität eher in der Anwendung als auf der Datenbankebene liegt.

Wir verwenden die Sitzung ausgiebig und wir beginnen zu denken, dass die Zeiten der korrupten Daten den Zeiten ähneln, in denen wir im Laufe des Tages Updates für das System bereitstellen.

Wir verwenden den aspnet_state-Dienst, um die Sitzung über Neustarts von Anwendungen fortzusetzen.

Unsere Benutzer verlassen sich auf Terminalsitzungen, daher melden sich mehrere Benutzer auf demselben Server an und starten das System über einen Browser.

Wir haben in der Vergangenheit festgestellt, dass sich Benutzer mit den gleichen Anmeldeinformationen anmelden, aber wir sind jetzt relativ zuversichtlich, dass sich Benutzer jetzt mit eindeutigen Konten anmelden.

99,9% der Daten sind korrekt, aber wir haben Mühe, zu verstehen, was dieses intermittierende Datenintegritätsproblem verursachen könnte.

Wir beschränken jetzt unsere Deploys auf die äußeren Arbeitszeiten bei Todesfolge, aber das ist nicht immer möglich.

Kann jemand herausfinden, warum/wie dies geschehen könnte?

EDIT: Wir haben nun diese auf die DAL Schicht isoliert, siehe SQL query returns incorrect value in multi user environment

Answer 1

Ich habe dies vor kurzem kämpfen !, und hatte ähnliches Problem bei Ihnen rund 95% der war richtig geschriebenen Daten zurück. Ich habe mir verschiedene Gründe angeschaut, warum der Hauptschuldige war, dass einige Nutzer im Netzwerk Chrome heruntergeladen und den Datensatz in Chrome geöffnet hatten, wodurch unsere Sitzungs-ID gebrochen wurde, da Chrome Sitzungen ignoriert.

Die andere Ursache war, dass entweder der Benutzer den Browser nicht schloss oder die Anwendung nicht abmeldete, wodurch entweder derselbe Benutzer oder ein völlig anderer Benutzer die Sitzungs-ID auswählen und verwenden konnte.

Nach der Einführung eines Browser-Checks und der Ablehnung von Chrome, der Schulung der Benutzer, um sicherzustellen, dass sie sich abmelden und Updates für Zeiten außerhalb der Geschäftszeiten vornehmen, war das Problem so gut wie verschwunden.

Ich habe vergessen zu erwähnen, auch auf Ihrem IIS ist es am besten, Caching im Output Caching zu deaktivieren, für den Benutzer und Kernel-Set Caching zu verhindern.