Transaktionsisolationsstufen (ODBC)
Transaktionsisolationsstufen sind ein Maß für den Umfang, in dem die Transaktionsisolation erfolgreich ist. Insbesondere werden Transaktionsisolationsstufen durch das Vorhandensein oder Fehlen der folgenden Phänomene definiert:
Dirty Reads A modifiziert Reads tritt auf, wenn eine Transaktion Daten liest, die noch nicht zugesichert wurden. Angenommen, Transaktion 1 aktualisiert eine Zeile. Transaktion 2 liest die aktualisierte Zeile vor dem Commit der Transaktion 1 für das Update. Wenn Transaktion 1 die Änderung zurückgibt, hat Transaktion 2 Lesedaten, die als nie vorhanden angesehen werden.
Nichtrepeatable Reads A nonrepeatable reads a nonrepeatable reads when a transaction reads the same row twice but gets different data each time. Angenommen, Transaktion 1 liest eine Zeile. Transaktion 2 aktualisiert oder löscht diese Zeile und führt einen Commit für das Update oder Löschen durch. Wenn Transaktion 1 die Zeile erneut liest, werden unterschiedliche Zeilenwerte abgerufen oder ermittelt, dass die Zeile gelöscht wurde.
Phantoms A Phantom ist eine Zeile, die den Suchkriterien entspricht, aber nicht anfänglich gesehen wird. Angenommen, Transaktion 1 liest eine Reihe von Zeilen, die einige Suchkriterien erfüllen. Transaktion 2 generiert eine neue Zeile (entweder durch eine Aktualisierung oder ein Einfügen), die den Suchkriterien für Transaktion 1 entspricht. Wenn Transaktion 1 die Anweisung erneut ausgeführt, die die Zeilen liest, erhält sie einen anderen Satz von Zeilen.
Die vier Transaktionsisolationsstufen (wie durch SQL-92 definiert) werden in Bezug auf diese Phänomene definiert. In der folgenden Tabelle markiert ein "X" jedes Phänomen, das auftreten kann.
| Transaktionsisolationsstufe | Dirty Reads | Nicht wiederholbare Lesevorgänge | Phantome |
|---|---|---|---|
| Read Uncommitted | X | X | X |
| Read Committed | -- | X | X |
| Repeatable Read | -- | -- | X |
| Serialisierbar | -- | -- | -- |
In der folgenden Tabelle werden einfache Möglichkeiten beschrieben, wie ein DBMS die Transaktionsisolationsstufen implementieren kann.
Wichtig
Die meisten DBMSs verwenden komplexere Schemas als diese, um die Parallelität zu erhöhen. Diese Beispiele werden nur zu Veranschaulichungszwecken bereitgestellt. Insbesondere schreibt ODBC nicht vor, wie bestimmte DBMS Transaktionen voneinander isolieren.
| Transaktionsisolation | Mögliche Implementierung |
|---|---|
| Read Uncommitted | Transaktionen sind nicht voneinander isoliert. Wenn dbMS andere Transaktionsisolationsstufen unterstützt, ignoriert sie den mechanismus, der zum Implementieren dieser Ebenen verwendet wird. Damit sie keine nachteiligen Auswirkungen auf andere Transaktionen haben, sind Transaktionen, die auf der Ebene "Unkommissionieren lesen" ausgeführt werden, in der Regel schreibgeschützt. |
| Read Committed | Die Transaktion wartet, bis Zeilen, die durch andere Transaktionen schreibgesperrt sind, gesperrt sind. dadurch wird verhindert, dass daten "modifiziert" gelesen werden. Die Transaktion enthält eine Lesesperre (wenn sie nur die Zeile liest) oder eine Schreibsperre (wenn sie die Zeile aktualisiert oder löscht) in der aktuellen Zeile, um zu verhindern, dass andere Transaktionen aktualisiert oder gelöscht werden. Die Transaktion gibt Lesesperren frei, wenn sie aus der aktuellen Zeile verschoben wird. Sie enthält Schreibsperren, bis sie zugesichert oder zurückgesetzt wird. |
| Repeatable Read | Die Transaktion wartet, bis Zeilen, die durch andere Transaktionen schreibgesperrt sind, gesperrt sind. dadurch wird verhindert, dass daten "modifiziert" gelesen werden. Die Transaktion enthält Lesesperren für alle Zeilen, die sie an die Anwendung zurückgibt, und schreibt Sperren für alle Zeilen, die eingefügt, aktualisiert oder gelöscht werden. Wenn die Transaktion beispielsweise die SQL-Anweisung SELECT * FROM Orders enthält, sperrt die Transaktion Zeilen, während die Anwendung sie abruft. Wenn die Transaktion die SQL-Anweisung DELETE FROM Orders WHERE Status = 'CLOSED' enthält, sperrt die Transaktion Zeilen, während sie gelöscht werden. Da andere Transaktionen diese Zeilen nicht aktualisieren oder löschen können, vermeidet die aktuelle Transaktion nicht wiederholbare Lesevorgänge. Die Transaktion gibt ihre Sperren frei, wenn sie zugesichert oder zurückgesetzt wird. |
| Serialisierbar | Die Transaktion wartet, bis Zeilen, die durch andere Transaktionen schreibgesperrt sind, gesperrt sind. dadurch wird verhindert, dass daten "modifiziert" gelesen werden. Die Transaktion enthält eine Lesesperre (wenn sie nur Zeilen liest) oder eine Schreibsperre (wenn sie Zeilen aktualisieren oder löschen kann) im Bereich der Zeilen, die sie betrifft. Wenn die Transaktion z. B. die SQL-Anweisung SELECT * FROM Orders enthält, ist der Bereich die gesamte Tabelle "Orders". Die Transaktion liest die Tabelle mit Lesesperren und lässt keine neuen Zeilen in die Tabelle einzufügen. Wenn die Transaktion die SQL-Anweisung DELETE FROM Orders WHERE Status = 'CLOSED' enthält, ist der Bereich alle Zeilen mit einem Status von "CLOSED"; die Transaktion sperrt alle Zeilen in der Tabelle "Orders" mit einem Status von "CLOSED" und lässt keine Zeilen einzufügen oder zu aktualisieren, sodass die resultierende Zeile den Status "GESCHLOSSEN" aufweist. Da andere Transaktionen die Zeilen im Bereich nicht aktualisieren oder löschen können, vermeidet die aktuelle Transaktion nicht wiederholbare Lesevorgänge. Da andere Transaktionen keine Zeilen in den Bereich einfügen können, vermeidet die aktuelle Transaktion Phantome. Die Transaktion gibt ihre Sperre frei, wenn sie zugesichert oder zurückgesetzt wird. |
Es ist wichtig zu beachten, dass sich die Transaktionsisolationsstufe nicht auf die Fähigkeit einer Transaktion auswirkt, ihre eigenen Änderungen zu sehen; Transaktionen können jederzeit alle vorgenommenen Änderungen sehen. Eine Transaktion kann z. B. aus zwei UPDATE-Anweisungen bestehen, von denen die Zahlung aller Mitarbeiter um 10 Prozent erhöht wird und die zweite die Zahlung aller Mitarbeiter über einen bestimmten Höchstbetrag auf diesen Betrag festlegt. Dies ist nur als einzelne Transaktion erfolgreich, da die zweite UPDATE-Anweisung die Ergebnisse der ersten sehen kann.