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