Concurrency Flashcards
Definition Concurrency
- beschäftigt sich mit dem Parallelbetrieb in Datenbanken
- Sicherstellen, dass eine Transaktion Ergebnisse liefert, die unabhängig von anderen Transaktionen sind
Grundregel Concurrency
Jede Transaktion läuft so ab, als sei allein im System
3 Concurrency Probleme
1) Problem der verlorengegangen Änderung
2) Problem der Abhängigkeit von nicht abgeschlossenen Transaktionen
3) Problem der Inkonsistenz der Daten
Problem der verlorengegangenen Änderung
Zwei Transaktionen ändern (fast) gleichzeitig. Eine Änderung geht verloren.
- grundsätzlich nicht erlaubt
- großes Problem in verteilten Systemen, sehr kritisch
Problem der Abhängigkeit von nicht abgeschlossenen Transaktionen
Daten werden gelesen, die mittels Rollback zurückgesetzt werden
- sieht harmlos aus
- Problem bei konsequenter Ausnutzung dieser Lücke
Problem der Inkonsistenz der Daten
Fehlerhafte Daten werden gelesen, wenn andere Transaktionen gleichzeitig ändern
- sieht harmlos aus, aber mit falschen Werten wird intern weiter gearbeitet
Konsequenz der 3 Probleme
- alle drei Probleme sind zu vermeiden
- Problem verlorengegangene Änderung sehr kritisch
- Probleme Abhängigkeit und Inkonsistenz bei “harmlosen” Transaktionen vorstellbar (z.B. Sammeln von einfachen Statistiken)
Concurrency Strategie: optimistisch
- jede TA darf beliebig lesen und ändern (Problem werden in Kauf genommen)
- bei TA-Ende wird auf parallele Zugriffe überprüft
- bei parallelem Zugriff: Rücksetzen und Neustart der TA
- Realisierung mit Zugriffszähler
- nur für sehr niedrige Kollisionswahrscheinlichkeit
- Gegenseitiges Aufschaukeln: Ständige Neustarts
Concurrency Strategie: pessimistisch
- alle Daten bei einer TA sind für alle anderen TAs gesperrt
- Freigabe der Sperre bei TA-Ende (Sperrmechanismen / Locks)
- Andere TAs müssen ggf. warten
- Einschränkung der Parallelität
- hoher Verwaltungsaufwand für Sperrmechanismen
Sperrmechanismen
- werden mit Locks realisiert
- zu jeder Relation existiert ein Lock
- TA holt vor jedem Zugriff automatisch den Lock der zuzugreifenden Relation
- wenn Lock von anderer TA belegt: TA wartet in Warteschlange auf Freigabe des Locks (Serialisierung)
- bei TA-Ende werden alle gehaltenen Locks freigegeben
Sperrgranulate
1) Datenbanksperre (kein Parallelbetrieb, nur für Einzelbetrieb)
2) Tabellensperre (flexible, bei geringer Parallelität gut einsetzbar, aber: intensiver Zugriff auf einzelne Tabellen)
3) Eintragssperren (enorm aufwändig, daher kaum implementiert)
4) Tupelsperren (Standard in größeren Datenbanken, aber sehr viele Locks (Tabellen * Zeilen))
Implementierung von Sperren
- Lockpool mit Poolverwaltung
- Locks werden bei Bedarf eingerichtet
Lesende Zugriffe und Concurrency
- in Praxis: 80 - 90% Lesezugriffe (sollen sich nicht gegenseitig behindern)
- Lesende dürfen Änderungen vor Commit der TA NICHT lesen
- Schreibende dürfen Daten NICHT ändern, wenn vorher von anderen gelesen (Inkonsistenz der Daten)
Exklusiv-Lock
Exklusiv-Lock auf ein Objekt weist alle weiteren Exklusiv- und Share-Lockanforderungen auf dieses Objekt zurück
Share-Lock
Ein Share-Lock auf ein Objekt gestattet weitere Share-Lockzugriffe auf dieses Objekt, weist aber exklusive Lockanforderungen zurück
Sperren in Datenbanken: vor Lesezugriff
- automatisches Anfordern eines Share-Locks
- TA erhält Share-Lock, wenn es keine anderen Exklusiv-Lock-Anforderungen anderer Transaktionen gibt
Sperren in Datenbanken: vor Schreibzugriff
- automatisches Anfordern eines Exklusiv-Locks
- TA erhält Exklusiv-Lock, wenn es keine anderen Share- oder Exklusiv-Lock-Anforderungen gibt
- hält die TA bereits Share-Lock, so wird dieser (sobald verfügbar) in Exklusiv-Lock umgewandelt
Definition Deadlock
Verklemmung, bei der mindestens zwei Transaktionen gegenseitig auf die Freigabe eines oder mehrerer Locks warten
- Lesende behindern Schreibende und umgekehrt
- Deadlocks können auch zwischen Lesenden und Schreibenden auftreten
Deadlockvermeidung
- anfordern von Locks in vorgegebener Reihenfolge (z.B. Relationen und Tupel alphabetisch oder nach Primärschlüssel geordnet) –> Zugriff gemäß Ordnung
- aber: zu Transaktionsbeginn nicht immer alle nötigen Tupel bekannt
Deadlock-Erkennung
- Wartezeiten-Prinzip hat Schwächen (Abbrechen “unschuldiger” TAs und verlängern der Antwortzeiten
- besser: Erkennen mittels Wartegraphen (Pfeil bei wartenden Transaktionen
- Wartegraph ist Standard moderner Datenbanken (geringer Implementierungsaufwand)
Deadlockauflösung
- SQL-Norm: Fehlermeldung SQLSTATE: 4000I
- Zurücksetzen und Neustarten der Transaktion, um durch Freigabe aller Locks die Verklemmung aufzulösen
Endergebnis: Probleme der Concurrency
- Problem lassen sich lösen durch Exklusiv- und Share-Locks, Lockerkennung, Rücksetzen und Neustarten der TA
- bei Deadlockfehlermeldung: TA zurücksetzen und ggf. neu starten
- Wiederholen eines DB-Zugriffs im Deadlockfall führt sofort wieder zum Deadlock
