Lesen festgeschrieben ist eine Isolationsstufe, die garantiert, dass alle gelesenen Daten festgeschrieben wurden im Moment wird gelesen. Es hindert den Leser einfach daran, irgendwelche dazwischenliegenden, nicht festgeschriebenen, „schmutzigen“ Lesevorgänge zu sehen. Es gibt keinerlei Versprechen, dass, wenn die Transaktion den Lesevorgang erneut ausgibt, das Gleiche gefunden wird Daten, Daten können sich nach dem Lesen frei ändern.
Repeatable Read ist eine höhere Isolationsstufe, die zusätzlich zu den Garantien der Read Committed-Stufe auch garantiert, dass alle gelesenen Daten nicht geändert werden können , wenn die Transaktion dieselben Daten erneut liest, findet sie die zuvor gelesenen Daten an Ort und Stelle, unverändert und zum Lesen verfügbar.
Die nächste Isolationsstufe, serialisierbar, bietet eine noch stärkere Garantie:Zusätzlich zu allen wiederholbaren Lesegarantien garantiert sie auch, dass keine neuen Daten kann durch ein nachfolgendes Lesen gesehen werden.
Angenommen, Sie haben eine Tabelle T mit einer Spalte C mit einer Zeile darin, sagen wir, sie hat den Wert '1'. Und stellen Sie sich vor, Sie haben eine einfache Aufgabe wie die folgende:
BEGIN TRANSACTION;
SELECT * FROM T;
WAITFOR DELAY '00:01:00'
SELECT * FROM T;
COMMIT;
Das ist eine einfache Aufgabe, die zwei Lesevorgänge von Tabelle T ausgibt, mit einer Verzögerung von 1 Minute zwischen ihnen.
- unter READ COMMITTED kann das zweite SELECT any zurückgeben Daten. Eine gleichzeitige Transaktion kann den Datensatz aktualisieren, ihn löschen, neue Datensätze einfügen. Die zweite Auswahl sieht immer das Neue Daten.
- unter REPEATABLE READ zeigt das zweite SELECT garantiert mindestens die Zeilen an, die vom ersten SELECT unverändert zurückgegeben wurden . Neue Zeilen können in dieser einen Minute durch eine gleichzeitige Transaktion hinzugefügt werden, aber die vorhandenen Zeilen können nicht gelöscht oder geändert werden.
- unter SERIALIZABLE liest die zweite Auswahl garantiert genau die gleichen Zeilen wie die erste. Durch eine gleichzeitige Transaktion können keine Zeilen geändert, gelöscht oder neue Zeilen eingefügt werden.
Wenn Sie der obigen Logik folgen, können Sie schnell erkennen, dass SERIALIZABLE-Transaktionen zwar das Leben erleichtern, aber immer vollständig blockieren jede mögliche gleichzeitige Operation, da sie erfordern, dass niemand Zeilen ändern, löschen oder einfügen kann. Die Standard-Transaktionsisolationsebene von .Net System.Transactions Bereich ist serialisierbar, und dies erklärt normalerweise die miserable Leistung, die daraus resultiert.
Und schließlich gibt es noch die Isolationsstufe SNAPSHOT. Die SNAPSHOT-Isolationsstufe bietet die gleichen Garantien wie serialisierbar, jedoch nicht, indem sie verlangt, dass keine gleichzeitige Transaktion die Daten ändern kann. Stattdessen zwingt es jeden Leser, seine eigene Version der Welt zu sehen (seinen eigenen „Schnappschuss“). Dies macht es sehr einfach, dagegen zu programmieren, sowie sehr skalierbar, da es gleichzeitige Updates nicht blockiert. Dieser Vorteil hat jedoch seinen Preis:zusätzlicher Serverressourcenverbrauch.
Ergänzende Lesezeichen:
- Isolationsstufen in der Datenbank-Engine
- Parallelitätseffekte
- Auswahl von zeilenversionsbasierten Isolationsstufen
