Optimistische vs. pessimistische Schließung

Question

Ich verstehe die Unterschiede zwischen optimistischen und pessimistischen Schließungen. Könnte mir jetzt jemand erklären, wann ich eine von beiden generell verwenden würde?

Und ändert sich die Antwort auf diese Frage, je nachdem, ob ich eine gespeicherte Prozedur zur Ausführung der Abfrage verwende oder nicht?

Aber nur zur Kontrolle: Optimistisch bedeutet "die Tabelle beim Lesen nicht sperren" und pessimistisch bedeutet "die Tabelle beim Lesen sperren".

Answer 1

Optimistische Verriegelung ist eine Strategie, bei der Sie einen Datensatz lesen, sich eine Versionsnummer notieren (andere Methoden, dies zu tun, beinhalten Datumsangaben, Zeitstempel oder Prüfsummen/Hashes) und überprüfen, ob sich die Version nicht geändert hat, bevor Sie den Datensatz zurückschreiben. Wenn Sie den Datensatz zurückschreiben, filtern Sie die Aktualisierung nach der Version, um sicherzustellen, dass sie atomar ist. (d. h. zwischen der Überprüfung der Version und dem Schreiben des Datensatzes auf den Datenträger wurde keine Aktualisierung vorgenommen) und aktualisieren Sie die Version auf einen Schlag.

Wenn der Datensatz schmutzig ist (d.h. eine andere Version als Ihre), brechen Sie die Transaktion ab, und der Benutzer kann sie erneut starten.

Diese Strategie eignet sich am besten für Systeme mit hohem Datenaufkommen und dreistufige Architekturen, bei denen Sie nicht unbedingt eine Verbindung zur Datenbank für Ihre Sitzung aufrechterhalten müssen. In dieser Situation kann der Client keine Datenbanksperren aufrechterhalten, da die Verbindungen aus einem Pool genommen werden und Sie möglicherweise nicht dieselbe Verbindung von einem Zugriff zum nächsten verwenden.

Pessimistische Sperrung ist, wenn Sie den Datensatz für die ausschließliche Verwendung durch Sie sperren, bis Sie mit ihm fertig sind. Diese Methode hat eine viel bessere Integrität als optimistisches Sperren, erfordert aber eine sorgfältige Planung der Anwendung, um Folgendes zu vermeiden Deadlocks . Um pessimistisches Sperren zu verwenden, benötigen Sie entweder eine direkte Verbindung zur Datenbank (wie es typischerweise bei einem zweistufiger Client-Server Anwendung) oder eine extern verfügbare Transaktions-ID, die unabhängig von der Verbindung verwendet werden kann.

In letzterem Fall öffnen Sie die Transaktion mit der TxID und stellen dann die Verbindung mit dieser ID wieder her. Das DBMS verwaltet die Sperren und ermöglicht es Ihnen, die Sitzung über die TxID wieder zu öffnen. Auf diese Weise werden verteilte Transaktionen mit zweiphasigen Commit-Protokollen (wie XA o COM+-Transaktionen ) arbeiten.

Answer 2

Beim Umgang mit Konflikten haben Sie zwei Möglichkeiten:

• Sie können versuchen, den Konflikt zu vermeiden, und das ist es, was Pessimistic Locking tut.
• Oder Sie können den Konflikt zulassen, aber Sie müssen ihn bei der Übergabe Ihrer Transaktionen erkennen, und das ist die Aufgabe von Optimistic Locking.

Betrachten wir nun die folgende Anomalie des verlorenen Updates:

Die Anomalie "Verlorene Aktualisierung" kann auf der Isolationsebene "Read Committed" auftreten.

Im obigen Diagramm können wir sehen, dass Alice glaubt, dass sie 40 von ihrem Konto abheben kann account merkt aber nicht, dass Bob gerade den Kontostand geändert hat und jetzt nur noch 20 auf dem Konto sind.

Pessimistische Sperrung

Pessimistisches Sperren erreicht dieses Ziel, indem es eine gemeinsame oder eine Lesesperre für das Konto einrichtet, so dass Bob daran gehindert wird, das Konto zu ändern.

In dem obigen Diagramm erhalten sowohl Alice als auch Bob eine Lesesperre für die Datei account Tabellenzeile, die beide Benutzer gelesen haben. Die Datenbank erwirbt diese Sperren auf SQL Server, wenn sie Repeatable Read oder Serializable verwendet.

Da sowohl Alice als auch Bob die account mit dem PK-Wert von 1 kann keiner von ihnen etwas ändern, bis ein Benutzer die Lesesperre aufhebt. Dies liegt daran, dass ein Schreibvorgang den Erwerb einer Schreib-/Exklusivsperre erfordert, und gemeinsam genutzte Lese-/Lesesperren verhindern Schreib-/Exklusivsperren.

Erst nachdem Alice ihre Transaktion bestätigt hat und die Lesesperre für die Datei account Reihe, Bob UPDATE wird fortgesetzt und die Änderung übernommen. Bis Alice die Lesesperre aufhebt, wird Bobs UPDATE blockiert.

Optimistische Verriegelung

Optimistic Locking lässt den Konflikt zu, entdeckt ihn aber bei der Anwendung von Alices UPDATE, da sich die Version geändert hat.

Dieses Mal haben wir eine zusätzliche version Spalte. Die version Spalte wird jedes Mal erhöht, wenn ein UPDATE oder DELETE ausgeführt wird, und sie wird auch in der WHERE-Klausel der UPDATE- und DELETE-Anweisungen verwendet. Damit dies funktioniert, müssen wir die SELECT-Anweisung ausführen und die aktuelle version vor der Ausführung des UPDATE oder DELETE, da wir sonst nicht wüssten, welchen Versionswert wir an die WHERE-Klausel übergeben oder inkrementieren sollen.

Transaktionen auf Anwendungsebene

Relationale Datenbanksysteme sind in den späten 70er und frühen 80er Jahren entstanden, als ein Client in der Regel über ein Terminal eine Verbindung zu einem Großrechner herstellte. Aus diesem Grund werden in Datenbanksystemen immer noch Begriffe wie SESSION-Einstellung definiert.

Heutzutage, im Internet, werden Lese- und Schreibvorgänge nicht mehr im Rahmen derselben Datenbanktransaktion ausgeführt, und ACID ist nicht mehr ausreichend.

Betrachten Sie zum Beispiel den folgenden Anwendungsfall:

Ohne optimistisches Sperren gibt es keine Möglichkeit, dass dieses verlorene Update abgefangen wird, selbst wenn die Datenbanktransaktionen Serializable verwenden. Der Grund dafür ist, dass Lese- und Schreibvorgänge in separaten HTTP-Anfragen und somit in verschiedenen Datenbanktransaktionen ausgeführt werden.

Optimistisches Sperren kann also dazu beitragen, verlorene Aktualisierungen zu verhindern, selbst wenn Sie Transaktionen auf Anwendungsebene verwenden, die auch die Denkzeit des Benutzers einbeziehen.

Schlussfolgerung

Optimistisches Sperren ist eine sehr nützliche Technik, die auch dann gut funktioniert, wenn weniger strenge Isolationsebenen wie Read Committed verwendet werden oder wenn Lese- und Schreibvorgänge in aufeinander folgenden Datenbanktransaktionen ausgeführt werden.

Der Nachteil des optimistischen Sperrens ist, dass ein Rollback durch das Datenzugriffs-Framework ausgelöst wird, wenn ein OptimisticLockException Dadurch geht die gesamte Arbeit verloren, die zuvor von der aktuell ausgeführten Transaktion geleistet wurde.

Je mehr Streitigkeiten, desto mehr Konflikte und desto größer ist die Wahrscheinlichkeit, dass Transaktionen abgebrochen werden. Rollbacks können für das Datenbanksystem kostspielig sein, da es alle anstehenden Änderungen rückgängig machen muss, die sowohl Tabellenzeilen als auch Indexsätze betreffen können.

Aus diesem Grund ist das pessimistische Sperren bei häufigen Konflikten möglicherweise besser geeignet, da es die Wahrscheinlichkeit eines Rollbacks von Transaktionen verringert.

Answer 3

Optimistisches Sperren wird verwendet, wenn man nicht viele Kollisionen erwartet. Es kostet weniger, einen normalen Vorgang auszuführen, aber wenn eine Kollision auftritt, zahlen Sie einen höheren Preis, um sie zu lösen, da die Transaktion abgebrochen wird.

Pessimistisches Sperren wird verwendet, wenn eine Kollision zu erwarten ist. Die Transaktionen, die die Synchronisierung verletzen würden, werden einfach blockiert.

Um einen geeigneten Sperrmechanismus auszuwählen, müssen Sie die Anzahl der Lese- und Schreibvorgänge abschätzen und entsprechend planen.

Answer 4

Optimistisch geht davon aus, dass sich nichts ändern wird, während Sie es lesen.

Pessimisten gehen davon aus, dass etwas passieren wird, und halten es deshalb fest.

Wenn es nicht unbedingt erforderlich ist, dass die Daten perfekt gelesen werden, verwenden Sie optimistisch. Es kann vorkommen, dass Sie "schmutzige" Daten lesen, aber die Wahrscheinlichkeit, dass es zu Deadlocks und ähnlichem kommt, ist weitaus geringer.

Die meisten Webanwendungen kommen mit unsauberen Lesevorgängen gut zurecht - in den seltenen Fällen, in denen die Daten nicht genau übereinstimmen, tut es der nächste Reload.

Für genaue Datenoperationen (wie bei vielen Finanztransaktionen) verwenden Sie pessimistisch. Es ist wichtig, dass die Daten genau gelesen werden, ohne nicht angezeigte Änderungen - der zusätzliche Sperr-Overhead ist es wert.

Oh, und Microsoft SQL Server ist standardmäßig auf Seitensperrung eingestellt - im Grunde die Zeile, die Sie gerade lesen, und ein paar auf jeder Seite. Zeilensperren sind genauer, aber viel langsamer. Es lohnt sich oft, Ihre Transaktionen auf Read-Committed oder No-Lock einzustellen, um Deadlocks beim Lesen zu vermeiden.

Answer 5

Mir fällt noch ein weiterer Fall ein, in dem ein pessimistischer Abschluss die bessere Wahl wäre.

Beim optimistischen Sperren müssen alle an der Datenänderung Beteiligten dieser Art des Sperrens zustimmen. Wenn jedoch jemand die Daten ändert, ohne sich um die Versionsspalte zu kümmern, wird die ganze Idee des optimistischen Sperrens zunichte gemacht.