Schreib-Lese-Konflikt
Ein Schreib-Lese-Konflikt (auch englisch dirty read) tritt in der Informatik auf, wenn von zwei gleichzeitig ablaufenden Transaktionen die eine Transaktion Daten liest, die von der anderen Transaktion geschrieben bzw. geändert werden, jedoch noch nicht bestätigt (committed) sind.
Beispiel
[Bearbeiten | Quelltext bearbeiten]Die folgende Transaktion könnte bei der Benutzeranmeldung in einem Wiki auftreten:
TransaktionsanfangTransaktionsende
Gleichzeitig könnte eine Funktion, mit der sich ein Benutzer eine Liste der angemeldeten Benutzer anzeigen lassen kann, die folgende Transaktion ausführen:
Transaktionsanfang- Selektiere alle Benutzerdatensätze (Aktion 2a)
- Gib die gefundenen Benutzerdaten als bunte Webseite aus
Transaktionsende
Ohne Transaktionsisolation kann es nun auf die folgende Weise zu einem Schreib-Lese-Konflikt kommen, der dazu führt, dass auch ein eigentlich noch nicht existierender Datensatz ausgegeben wird:
| Zeitpunkt | Transaktion 1 | Transaktion 2 | Wirkung |
|---|---|---|---|
| 1 | Aktion 1a | Benutzerdatensatz wird vorübergehend angelegt | |
| 2 | Aktion 1b | Sperrliste wird gelesen; Benutzer ist gesperrt | |
| 3 | Aktion 2a | Vorläufiger Benutzerdatensatz wird mit ausgegeben | |
| 4 | Rollback | Vorläufig angelegter Datensatz wird wieder entfernt |
Abhilfe
[Bearbeiten | Quelltext bearbeiten]Datenbanken bieten üblicherweise die Möglichkeit der Transaktionsisolation. Bei Isolation durch Serialisierung könnte der obige Ablauf beispielsweise wie folgt aussehen; der Schreib-Lese-Konflikt wird vermieden:
| Zeitpunkt | Transaktion 1 | Transaktion 2 | Wirkung |
|---|---|---|---|
| 1 | Aktion 1a | Benutzerdatensatz wird vorübergehend angelegt | |
| 2 | Aktion 1b | Sperrliste wird gelesen; Benutzer ist gesperrt | |
| 3 | Aktion 2a | Tabelle gesperrt: Transaktion muss warten | |
| 4 | Rollback | Vorläufig angelegter Datensatz wird wieder entfernt | |
| 5 | Aktion 2a | Transaktion wird fortgeführt, vorläufiger Eintrag wird nicht mit ausgegeben |