Dirty Read, Phantom Read, nicht wiederholbarer Lesevorgang und verlorene Update-Instanzen

Am 5. Juni 2017 war das Wetter regnerisch.

Als ich vor zwei Tagen meine vorherigen Studiennotizen sortierte, stellte ich fest, dass die durch Transaktionsparallelität verursachten Probleme – Dirty Reads, Phantom Reads, nicht wiederholbare Lesevorgänge und verlorene Aktualisierungen – etwas vage sind, also habe ich sie überprüft Sie noch einmal, und jetzt habe ich einige meiner Erkenntnisse zur besseren Übersichtlichkeit wie folgt zusammengefasst.

Sperre ist ein Mittel, um zu verhindern, dass andere Transaktionen auf bestimmte Ressourcen zugreifen. Sperren sind die Hauptmethode zur Erzielung einer Parallelitätskontrolle und eine wichtige Garantie dafür, dass mehrere Benutzer gleichzeitig Daten in derselben Datenbank bearbeiten können, ohne dass es zu Dateninkonsistenzen kommt. Im Allgemeinen verhindern Sperren Dirty Reads, nicht wiederholbare Lesevorgänge und Phantom Reads.

1.Dirty Read – Eine Transaktion liest Daten, die von einer anderen Transaktion nicht festgeschrieben wurden.

Detaillierte Erklärung: Wenn eine Transaktion auf Daten zugreift und die Daten ändert, die Änderung jedoch noch nicht an die Datenbank übermittelt wurde, greift eine andere Transaktion ebenfalls auf die Daten zu und verwendet sie dann. Da diese Daten noch nicht festgeschrieben wurden, handelt es sich bei den von einer anderen Transaktion gelesenen Daten um fehlerhafte Daten, und die auf den fehlerhaften Daten basierenden Vorgänge sind möglicherweise falsch.

Transaktion T1: Ein Datenelement aktualisieren
-->Transaktion T2: Den durch Transaktion T1 aktualisierten Datensatz lesen
Transaktion T1: Commit zum Commit aufrufen
Zu diesem Zeitpunkt liest Transaktion T2 Daten sind im Datenbankspeicher gespeicherte Daten, die als Dirty Data bezeichnet werden. Dieser Vorgang wird als Dirty Reading bezeichnet.

Dirty Reading tritt auf, wenn eine Transaktion A Daten liest, die von einer anderen Transaktion B geändert, aber noch nicht festgeschrieben wurden. Wenn B ein Rollback durchführt, liest Transaktion A ungültige Daten. Dies ähnelt einem nicht wiederholbaren Lesevorgang, die zweite Transaktion muss jedoch nicht festgeschrieben werden.

Lösen Sie das Dirty-Read-Problem: Fügen Sie beim Ändern eine exklusive Sperre hinzu und geben Sie sie frei, bis die Transaktion festgeschrieben wird. Geben Sie nach dem Lesen Transaktion 1 frei und fügen Sie beim Lesen von Daten eine gemeinsame Sperre hinzu dass nach der Transaktion 1. Während des Lesevorgangs die Daten nicht von anderen Transaktionen geändert werden dürfen, darf keine Transaktion mit den Daten arbeiten, sie können nur gelesen werden. Nach 1 erfolgt ein Aktualisierungsvorgang In eine exklusive Sperre umgewandelt, und andere Transaktionen haben keine Lese- und Schreibrechte, wodurch Probleme mit schmutzigen Lesevorgängen vermieden werden. Wenn jedoch Transaktion 1 die Daten liest, ist es möglich, dass auch andere Transaktionen die Daten gelesen haben. Nach Abschluss des Lesevorgangs wird die gemeinsame Sperre aufgehoben. Zu diesem Zeitpunkt ändert Transaktion 1 die Daten. Wenn andere Transaktionen die Daten erneut lesen, treten nicht wiederholbare Leseprobleme auf, sodass nicht wiederholbare Leseprobleme auftreten können.

2.Phantomlesung (Phantom)——In derselben Transaktion wird derselbe Vorgang zweimal zum Lesen verwendet, und die Anzahl der erhaltenen Datensätze ist unterschiedlich.

Detaillierte Erklärung: Phantomlesen bezieht sich auf ein Phänomen, das auftritt, wenn Transaktionen nicht unabhängig voneinander ausgeführt werden. Beispielsweise werden bei der ersten Transaktion die Daten in einer Tabelle geändert, und diese Änderung betrifft alle Daten in der Tabelle. Gleichzeitig werden durch die zweite Transaktion auch die Daten in dieser Tabelle geändert. Durch diese Änderung wird eine Zeile mit neuen Daten in die Tabelle eingefügt. Dann wird der Benutzer, der die erste Transaktion ausführt, in Zukunft feststellen, dass die Tabelle immer noch unveränderte Datenzeilen enthält, als ob eine Halluzination aufgetreten wäre.

Transaktion T1: Alle Datensätze in der Tabelle abfragen
                                                                                                                                                                                                 ; Alle Datensätze
in
Zu diesem Zeitpunkt sind die von Transaktion T1 zweimal abgefragten Datensätze unterschiedlich, was als Phantomlesung bezeichnet wird.

Hinweis: Beim Phantomlesen geht es um das Hinzufügen oder Löschen.

Phantomlesung tritt auf, wenn zwei identische Abfragen ausgeführt werden und die von der zweiten Abfrage zurückgegebene Ergebnismenge sich von der ersten Abfrage unterscheidet.

Was passiert: Keine Oszilloskopsperre.

So vermeiden Sie: Implementieren Sie den Serialisierungsisolationsmodus, der bei jeder Isolation auf niedriger Ebene auftreten kann.

Lösung des Phantomleseproblems: Der Bereichssperrmodus RangeS RangeS_S wird verwendet, um den Suchbereich als schreibgeschützt zu sperren und so das Phantomleseproblem zu vermeiden.

3.

Nicht wiederholbares Lesen

——In derselben Transaktion werden dieselben Daten zweimal gelesen und der Inhalt ist unterschiedlich. Transaktion T1: Einen Datensatz abfragen

                      --                                                                                                                                                                                                        Der letzte Datensatz

Zu diesem Zeitpunkt fragt Transaktion T1 dieselben Daten zweimal ab und der verfügbare Inhalt ist unterschiedlich, was als nicht- wiederholbare Lektüre.


Hinweis: Nicht wiederholbares Lesen konzentriert sich auf die Änderung.

Wenn bei der sperrenbasierten Parallelsteuerungsmethode beim Ausführen von select keine Lesesperre hinzugefügt wird, tritt ein nicht wiederholbares Leseproblem auf. Wenn im Parallelkontrollmechanismus mit mehreren Versionen eine Transaktion, bei der ein Festschreibungskonflikt auftritt, zurückgesetzt werden muss, aber freigegeben wird, tritt ein nicht wiederholbares Leseproblem auf.

Es gibt zwei Strategien, um das Auftreten dieses Problems zu verhindern:

(1) Verschieben Sie die Ausführung von Transaktion 2, bis Transaktion 1 festgeschrieben oder zurückgesetzt wird. Diese Strategie gilt bei der Verwendung von Sperren.

(2) Bei der parallelen Steuerung mehrerer Versionen kann Transaktion 2 zuerst übermittelt werden, während Transaktion 1 weiterhin mit der alten Datenversion ausgeführt wird. Wenn Transaktion 1 schließlich versucht, ein Commit durchzuführen, prüft die Datenbank, ob das Ergebnis mit dem Ergebnis übereinstimmt, als Transaktion 1 und Transaktion 2 nacheinander ausgeführt wurden. Wenn ja, wird Transaktion 1 erfolgreich übermittelt; andernfalls wird Transaktion 1 zurückgesetzt.

Lösen Sie das Problem des nicht wiederholbaren Lesens: Fügen Sie beim Lesen von Daten gemeinsame Sperren hinzu, fügen Sie beim Schreiben von Daten exklusive Sperren hinzu und geben Sie die Sperren erst nach der Übermittlung der Transaktion frei. Beim Lesen dürfen die Daten nicht durch andere Dinge geändert werden. Unabhängig davon, wie oft die Daten während der Transaktion gelesen werden, sind die Daten konsistent, wodurch das Problem des nicht wiederholbaren Lesens vermieden wird.
4.Verlorenes Update (Verlorenes Update)

Transaktion T1 liest die Daten, führt einige Vorgänge aus und aktualisiert dann die Daten. Auch die Transaktion T2 macht das Gleiche. Wenn also T1 und T2 Daten aktualisieren, können sie sich gegenseitig überschreiben, was zu Fehlern führt.

5. Um die oben genannten Isolationsstufenprobleme zu lösen, verwenden Sie die folgende Methode:

Es gibt fünf Stufen der Transaktionsisolation:
(1) TRANSACTION_NONE verwendet keine Transaktionen.
(2) TRANSACTION_READ_UNCOMMITTED ermöglicht Dirty Reads.
(3) TRANSACTION_READ_COMMITTED verhindert Dirty Reads, die am häufigsten verwendete Isolationsstufe und ist die Standardisolationsstufe für die meisten Datenbanken.
(4) TRANSACTION_REPEATABLE_READ kann Dirty Reads und nicht wiederholbare Reads verhindern.
(5) TRANSACTION_SERIALIZABLE kann Dirty Reads, nicht wiederholbare Reads und Phantom Reads verhindern, was (Transaktionsserialisierung) die Effizienz der Datenbank verringert.

Die oben genannten fünf Transaktionsisolationsstufen sind statische Konstanten, die in der Verbindungsschnittstelle definiert sind. Verwenden Sie die Methode setTransactionIsolation(int level), um die Transaktionsisolationsstufe festzulegen.

Zum Beispiel: con.setTransactionIsolation(Connection.REPEATABLE_READ).

Hinweis: Die Isolationsstufe einer Transaktion wird durch die Datenbank begrenzt. Die von verschiedenen Datenbanken unterstützten Isolationsstufen sind nicht unbedingt gleich.

Das obige ist der detaillierte Inhalt vonDirty Read, Phantom Read, nicht wiederholbarer Lesevorgang und verlorene Update-Instanzen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!