ASP.NET MVC - Datenbank-Parallelität

Der Umgang mit der Übereinstimmung Bei Webanwendungen ist dies eines der Themen, denen wir ein wenig Zeit widmen müssen, da aufgrund der Natur der Anwendung Fälle auftreten können, in denen mehrere Benutzer mit demselben Element interagieren müssen.
An sich ist Interaktion Es ist kein Problem, das eigentliche Problem tritt auf, wenn dieses Element nach der Änderung oder Berührung in der Datenbank gespeichert werden muss und dann zwei oder mehr Benutzer gleichzeitig eine Aktion am selben Element ausführen möchten unsere Logik muss ein Verhalten definieren, um zu wissen, wie man damit richtig umgeht.
Wie wir eingangs erklärt haben, ist die Übereinstimmung Dies ist der Fall, wenn zwei oder mehr Akteure an einem Element in unserer Anwendung arbeiten und eine Aktion für die Datenbank generieren.
ParallelitätsfallProbleme können auftreten, wenn die Änderungen widersprüchlich sind, zum Beispiel: Benutzer A hat einen Wert gespeichert, aber Benutzer B hat zu diesem Zeitpunkt auch geändert und einen anderen Wert gespeichert, in den Augen von Benutzer A wurde sein Inhalt nicht geändert und in den Augen der Benutzer B konnte ihn nichts daran hindern, seine Änderung vorzunehmen.
Diese Art von Konflikten kann die Leistung unserer Anwendung in den Augen des Benutzers beeinträchtigen, daher müssen wir prüfen, ob es sich lohnt, die Bereiche, die wir haben, für die Parallelität zu programmieren oder nicht.
Lass uns welche sehen Arten der Parallelität, auf diese Weise können wir etwas besser verstehen, welche Art von Aktionen wir in unseren Anwendungen ausführen können:
Pessimistische ParallelitätDieser Ansatz schlägt vor, dass wir bei der Verwendung der Datenbank a präventives Blockieren der verwendeten Registry, damit vermeiden wir, dass mehrere Benutzer den Wert gleichzeitig ändern, das Problem führt dazu, dass dies in der Webumgebung nicht vollständig möglich ist, da es keine Zustände gibt, wir nicht wirklich wissen, ob die Sperre angewendet oder entfernt wurde, bis wir mit dem Server kommunizieren, was zu Verwirrung und Langsamkeit bei der Nutzung führte.
Optimistische WahlbeteiligungDieser andere Ansatz ist stattdessen etwas mit dem Web kompatibel. Beim Ändern wird vor dem Speichern in der Datenbank überprüft, ob die Daten ab dem Zeitpunkt des Lesens nicht geändert wurden. Dazu vergleichen wir die Datensatzwerte und ein zugehöriges Feld, das für eine höhere Genauigkeit einen Zeitstempel mit Datum, Uhrzeit und Sekunden trägt.
ASP.NET MVC Es unterstützt nicht den pessimistischen Ansatz, daher müssen wir mit dem optimistischen Ansatz arbeiten. Dazu müssen wir unsere Strukturen mit Datumsfeldern versehen, um die letzte Änderung zu speichern, damit wir wissen können, ob der Wert geändert wurde, nachdem wir den Datensatz erhalten haben und vor dem Speichern können wir damit eine Warnung erhalten und so entscheiden, ob diese Werte überschrieben werden sollen oder nicht.
Sehen wir uns ein kleines Codebeispiel an, wie wir dies überprüfen könnten:

Wir bemerken dann, dass wir bei einer Änderung in der Datenbank überprüfen, ob das Feld nach dem Lesen geändert wurde, wenn ja Wir erheben eine Ausnahme, damit können wir die entsprechenden Maßnahmen ergreifen, wir lassen auch Platz, um an den verschiedenen Ausnahmen zu arbeiten, die möglicherweise generiert werden.
Am Ende dieses Tutorials wissen wir bereits ein wenig mehr über Parallelität in Datenbanken und wie man das Problem in bearbeitet ASP.NET MVC.