Isolationsgrad Repeatable Read
In der dritten von vier Isolationsstufen, auch Repeatable Read genannt, wird während der Transaktion ein konsistenter Lese- und Schreibzugriff gewährleistet.Der Isolationsmodus verwendet Sperren auf Objekten, die einem Lese- oder Schreibzugriff unterworfen sind. Dadurch können andere Transaktionen keine Änderungen an den verwendeten Objekten durchführen. Dies war ein Problem bei der Isolationsebene Read Committed.
Diese setzt zwar eine dauerhafte Schreibsperre, gelesene Objekte werden jedoch sofort wieder freigegeben.
Vorteile und Nachteile der Isolationsstufe Repeatable Read
Mit dem Isolationsgrad Repeatable Read wird das Auftreten von Dirty Read, Lost Update und dem Repeatable Read verhindert. Die Daten weisen nach der Transaktion einen konsistenten Zustand auf. Für Schreiboperationen eignet sich diese Isolationsstufe am besten, da sie die schwerwiegendste Anomalie (Lost Update) verhindert und gleichzeitig einen parallelen Mehrbenutzerbetrieb performant ermöglicht.
Aufgrund der eingesetzten Sperrverfahren, kann es vermehrt zu Verklemmungen (Deadlocks) im Datenbankmanagementsystem kommen. Diese müssen über das Transaktionsmanagement erkannt und beseitigt werden. Zudem kann es zu Verzögerungen in der Ausführung von Transaktionen kommen, wenn benötigte Objekte noch von anderen laufenden Transkationen gesperrt sind. Das Phantom Problem kann hierdurch nicht beseitigt werden.
Anwendungsbeispiel für den Isolationsgrad Repeatable Read
Die Transaktionsisolation Repeatable Read ist immer dann sinnvoll, wenn während einer Transaktion keine Änderungen durch parallele Vorgänge auf der Datenbank beeinträchtigt werden sollen. In dem Beispiel eines Bankkunden gehen wir davon aus, dass sich während der Sitzung keine Änderungen durch fremde Transaktionen auswirken sollen. Schaut der Kunde nach seinem Kontostand und führt er anschließend eine Überweisung von 500€ an seinen Vermieter durch, so ist es korrekt, dass der neue Kontostand minus der 500€ angezeigt wird.
Das Banksystem soll jedoch keine automatischen Änderungen vornehmen dürfen, während der Kunde angemeldet ist. So würde es einen nicht nachvollziehbaren Kontostand geben, wenn das System im Hintergrund 200€ auf das Konto zu bucht. Erst wenn sich der Kunde vom System abgemeldet hat, sollen andere Transkationen Buchungen vornehmen können.
