IT-Academy Logo
Sign Up Login Help
Home - Programmieren - Datenbanken - Synchronisationsprobleme



Synchronisationsprobleme

Im Artikel über Transaktionen wurde ausführlich darauf eingegangen, wie Operationen auf eine Datenbank ausgeführt werden müssen, damit es im Betrieb nicht zu Anomalien kommt (ACID-Prinzip). Arbeitet eine Datenbank nicht nach dem ACID-Prinzip, so kann dies zu Synchronisationsproblemen führen. Diese werden in diesem Artikel erläutert.


Autor: Patrick Bucher (paedubucher)
Datum: 10-07-2007, 21:36:46
Referenzen: keine
Schwierigkeit: Fortgeschrittene
Ansichten: 3355x
Rating: Bisher keine Bewertung.

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Lost-Update

Greifen mehrere Benutzer gleichzeitig schreibend auf den selben Datenbestand zu, kann das Lost Update-Problem auftreten.

Benutzer A

Benutzer B
Lese Wert aus Tabelle
Wert = 8
Puffer = Wert 8 + 2 (10)
Lese Wert aus Tabelle
Wert = 8
Puffer = Wert + 5 (13)
Aktualisiere Wert (Wert = 10)
Aktualisiere Wert (Wert = 13)
Lese Wert aus Tabelle (13)Lese Wert aus Tabelle (13)

Benutzer A erwartet, dass der Wert nach seiner Änderung 10 beträgt. Benutzer B hat die Daten jedoch in der Zwischenzeit geändert, sodass der Wert auf der Datenbank tatsächlich 13 beträgt. Die Änderungen von Benutzer A wurden also vergessen (Lost Update). Dieses Phänomen wird auch als "wer zuletzt speichert, gewinnt" bezeichnet.

Würden die beiden Transaktionen atomar ablaufen, so würde jeder Benutzer nach seiner Aktualisierung den korrekten Wert in der Datenbank vorfinden.

Dirty Read

Die Problematik beim Dirty Read ist recht ähnlich zur Lost Update-Problematik. In diesem Fall geht es jedoch darum, dass beim Herauslesen von Werten auch unbestätigte Transaktionen berücksichtigt werden.

Benutzer A

Benutzer B
Lese Wert aus Tabelle
Wert = 16
Puffer = Wert + 5 (21)
Aktualisiere Wert (Wert = 21)
Lese Wert aus Tabelle
Wert = 21
Puffer = Wert + 20 (41)
Aktualisiere Wert (Wert = 41)
Absturz (ROLLBACK)
Lese Wert aus Tabelle
Wert = 41
Lese Wert aus Tabelle
Wert = 41

Benutzer B liest den Wert 21 aus der Datenbank, dieser wurde jedoch innerhalb der Transaktion von Benutzer A noch nicht bestätigt. Benutzer B arbeitet aber dennoch mit diesen Daten und aktualisiert den Wert auf der Datenbank. Benutzer A führt nun einen ROLLBACK vor, sodass der Wert eigentlich wieder 16 (Anfangswert) betragen müsste. Da die Transaktion von Benutzer B den Wert jedoch aktualisiert hat und somit die unbestätigte Änderung von Benutzer A beinhaltet, findet Benutzer A am Ende nicht den Wert 16, sondern den Wert 41 vor.

Das Problem besteht darin, dass Benutzer B Werte aus der Datenbank lesen kann, die gerade von Benutzer A bearbeitet werden. Die Transaktion läuft somit nicht isoliert ab.

Nonrepeatable Read

Wird innerhalb einer Transaktion ein Wert mehrmals nacheinander abgefragt, so muss immer das gleiche Ergebnis zurückgeliefert werden.

Benutzer A

Benutzer B
Lese Wert aus Tabelle
Wert = 35
Aktualisiere Wert (Wert = 50)
Lese Wert aus Tabelle
Wert = 50Lese Wert aus Tabelle

Solange Benutzer A lesend auf die Daten zugreift, dürfen diese nicht von einer anderen Transaktion geändert werden. Die Transaktionen von Benutzer A und B laufen somit nicht isoliert voneinander ab. Dieses Problem bezeichnet man als Nonrepeatable Read.

Phantome

Phantome treten auf, wenn eine Transaktion laufend Daten aus der Datenbank heraus liest, mit diesen Daten vorweg Berechnungen anstellt und manche Daten in der Zwischenzeit von einer anderen Transaktion geändert werden.

Benutzer A

Benutzer B
[Wert I = 31, Wert II = 43]
Lese Wert I aus Tabelle
Wert I = 31
Wert II = 22
Aktualisiere Wert II
Lese Wert II aus Tabelle
Wert II = 22
Puffer = Wert I + Wert II (53)

Am Anfang der Transaktion beträgt Wert I 31, Wert II 43. Eine Addition aus diesen Werten würde somit 74 ergeben. Im Laufe der Transaktion wird Wert II jedoch aktualisiert und beträgt nun 22. Am Ende der Transaktion von Benutzer A beträgt die Summe dieser beiden Werte somit 53. Solange die Transaktion von Benutzer A lesend auf den Datenbestand zugreift, darf keine andere Transaktion schreibend darauf zugreifen.

Wie bei der Nonrepeatable Read-Problematik, laufen die Transaktionen nicht isoliert voneinander ab.



dreamer
Expert
Beitrag vom:
18-07-2007, 23:39:50

Die Admins werden von Kommentaren nicht automatisch benachrichtigt. Du versuchst es besser nochmal im Forum oder mit einer direkten Mail.

-----------------------------------------------------


paedubucher
Professonial
Beitrag vom:
10-07-2007, 22:16:26

Grafik fehlt

Bei der ersten Tabelle ist die Grafik (Datenbank) vorhanden. Bei den Tabellenn 2-4 jedoch nicht mehr. Könnte das jemand korrigieren? Beim Hochladen (Vorschau) wurden die Grafiken richtig eingebunden.

-----------------------------------------------------


[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04510
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06247
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1158
Comments: 0