Parallelitätseffekte
Benutzer, die Daten ändern, können einen Konflikt mit anderen Benutzern verursachen, die die gleichen Daten zur gleichen Zeit lesen oder ändern. Durch diese Benutzer erfolgt ein gleichzeitiger Zugriff auf die Daten. Wenn ein Datenspeichersystem keine Steuerung für die Parallelität besitzt, können Benutzer die folgenden Auswirkungen feststellen:
- Verlorene Aktualisierungen.
- Abhängigkeit von Daten, für die kein Commit ausgeführt wurde (Dirty Read).
- Inkonsistente Analyse (nicht wiederholbarer Lesevorgang).
- Phantomlesezugriffe.
Verlorene Aktualisierungen
Verlorene Aktualisierungen treten auf, wenn mindestens zwei Transaktionen dieselbe Zeile auswählen und diese Zeile dann auf der Grundlage des ursprünglich ausgewählten Wertes aktualisieren. Eine einzelne Transaktion ist nicht über die anderen Transaktionen informiert. Die letzte Aktualisierung überschreibt Aktualisierungen von anderen Transaktionen; dies führt zu Datenverlusten.
Nehmen Sie beispielsweise an, dass zwei Redakteure eine elektronische Kopie desselben Dokuments erstellen. Jeder Redakteur ändert die eigene Kopie und speichert die geänderte Kopie anschließend, wodurch das Originaldokument überschrieben wird. Der Redakteur, der die Kopie zuletzt speichert, überschreibt die Änderungen des anderen Redakteurs. Das Problem könnte vermieden werden, wenn einer der Redakteure erst auf die Datei zugreifen kann, nachdem der andere Redakteur seine Arbeit beendet und ein Commit der Transaktion ausgeführt hat.
Abhängigkeit von Daten, für die kein Commit ausgeführt wurde (Dirty Read)
Die Abhängigkeit von Daten, für die kein Commit ausgeführt wurde, tritt dann ein, wenn eine zweite Transaktion eine Zeile auswählt, die von einer anderen Transaktion aktualisiert wird. Die zweite Transaktion liest Daten, für die noch kein Commit ausgeführt wurde und die von der Transaktion, die die Zeile aktualisiert, noch geändert werden können.
Angenommen, ein Redakteur nimmt Änderungen an einem elektronischen Dokument vor. Während die Änderungen vorgenommen werden, verteilt ein zweiter Redakteur eine Kopie des Dokuments mit allen bisherigen Änderungen an die Zielgruppe. Der erste Redakteur entscheidet dann, dass die bisherigen Änderungen falsch sind, löscht sie und speichert das Dokument. Das verteilte Dokument enthält nun Änderungen, die nicht mehr vorhanden sind und so behandelt werden müssten, als ob sie nie vorhanden gewesen wären. Dieses Problem könnte vermieden werden, wenn das geänderte Dokument erst dann gelesen werden könnte, wenn der erste Redakteur die endgültige Speicherung der Änderungen vorgenommen und ein Commit der Transaktion ausgeführt hat.
Inkonsistente Analyse (nicht wiederholbarer Lesevorgang)
Die inkonsistente Analyse tritt dann ein, wenn eine zweite Transaktion mehrmals auf dieselbe Zeile zugreift und jedes Mal verschiedene Daten liest. Die inkonsistente Analyse ist vergleichbar mit der Abhängigkeit von Daten, für die kein Commit ausgeführt wurde, da auch in diesem Fall eine andere Transaktion die Daten ändert, die eine zweite Transaktion liest. Bei der inkonsistenten Analyse wurde jedoch für die von der zweiten Transaktion gelesenen Daten ein Commit von der Transaktion, die die Änderung vornahm, ausgeführt. Darüber hinaus umfasst die inkonsistente Analyse mehrere Lesevorgänge (mindestens zwei) derselben Zeile, wobei jedes Mal die Informationen von einer anderen Transaktion geändert wurden; der Begriff "Nicht wiederholbarer Lesevorgang" bezieht sich auf diesen Vorgang.
Angenommen, ein Redakteur liest dasselbe Dokument zweimal, doch zwischen den einzelnen Lesedurchgängen schreibt der Verfasser das Dokument um. Wenn der Redakteur das Dokument zum zweiten Mal liest, unterscheidet es sich von der ersten Version. Der ursprüngliche Lesevorgang lässt sich nicht wiederholen. Dieses Problem könnte vermieden werden, wenn der Verfasser das Dokument erst ändern könnte, nachdem der Redakteur den letzten Lesevorgang beendet hat.
Phantomlesezugriffe
Ein Phantomlesezugriff tritt dann ein, wenn ein Einfügungs- oder Löschvorgang in einer Zeile vorgenommen wird, die zu einem Zeilenbereich gehört, der von einer Transaktion gelesen wird. Der erste Lesevorgang der Transaktion des Zeilenbereichs zeigt eine Zeile, die im zweiten Lesevorgang oder den nachfolgenden Lesevorgängen aufgrund einer Löschung durch eine andere Transaktion nicht mehr vorhanden ist. Als Folge einer Einfügung durch eine andere Transaktion zeigt der zweite Lesevorgang oder nachfolgende Lesevorgänge einer Transaktion eine Zeile an, die beim ursprünglichen Lesevorgang nicht vorhanden war.
So wäre es z. B. möglich, dass ein Redakteur Änderungen an einem Dokument eines Verfassers vornimmt. Von der Produktionsabteilung wird später beim Einfügen der Änderungen in die Hauptversion des Dokuments festgestellt, dass der Verfasser dem Dokument neues, unbearbeitetes Material hinzugefügt hat. Dieses Problem könnte ähnlich wie bei einem nicht wiederholbaren Lesevorgang vermieden werden, wenn neue Teile zu einem Dokument erst dann hinzugefügt werden können, wenn der Redakteur und die Produktionsabteilung die Bearbeitung der ursprünglichen Version des Dokuments abgeschlossen haben.
Siehe auch
Konzepte
Parallelitätskontrolltypen
Isolationsstufen im Datenbankmodul