Serialisierbarkeit (Datenbanken)
Definitionen #
Operationen einer Transaktion
lesen von
schreiben von
abort
commit
“happend before relationship”
Konsistenzanforderungen #
Alle Operationen müssen vor einem abort oder commit durchgeführt werden.
-
- oder
-
Reads und writes haben eine Reihenfolge
-
- oder
-
Historie #
-
-
ist die Union aller Transaktionen
-
-
enthält alle "happened before relationships" aller Transaktionen einzeln und eventuell noch ein paar mehr zwischen den Transaktionen (die zum gleichen Ergebnis führen würden)
Konfliktoperationen #
Zwischen reads und writes zweier Transaktionen und
treten in
folgenden Fällen Konflikte auf:
und
: Die Reihenfolge ist entscheident
und
: Auch hier ist die Reihenfolge entscheident
Für zwei Konfliktoperationen und
gilt daher etweder:
-
- oder
-
Serialisierbar #
Eine Historie ist serialisierbar, wenn sie äquivalent zu einer
seriellen Historie ist.
Das ist der Fall wenn der Serialisierbarkeitsgraph kreisfrei ist.
Serialisierbarkeitsgraph #
- Ein Graph mit den Transaktionen als Knoten.
- Kanten (
) werden gebildet aus:
-
-
-
-
Konfliktoperationen in der Historie führen zu einer Kante
-
Beispiel #
führt zu
“Liest von” Beziehung #
liest von
in
wenn gilt:
-
-
UND
wird vor dem read nicht aborted:
-
UND alle writes die zwischendrin auf
passiert sind wurden bis zum read aborted.
Beispiel serialisierbar #
Kann serialisiert werden zu:
Beispiel nicht serialisierbar #
Eigenschaften von Historien #
Rücksetzbar (RC) #
Alle Transaktionen von denen gelesen wurde, wurden committed bevor
wir (
) comitten dürfen.
Einfaches Kriterium, kann aber zu cascading aborts führen, da lesende Transaktionen vor dem Commit merken, dass die schreibenden TAs aborted wurden.
Avoiding Cascading Abort (ACA) #
Wenn
ist sichergestellt, dass es keine cascading aborts gibt, da die Daten schon
committet sind. Es gibt keine dirty reads.
Strikte Historien (ST) #
Wenn
für irgendwelche operationen , dann wurde
davor committet
oder abortet.
-
- ODER
-
Serialisierbar (SR) #
siehe oben