Transaktions-Synchronisation (Datenabnken)

Zwei Arten von locks:

• shared (S)
• exlcusive (X)

Shared locks können immer genommen werden, außer jemand hat ein exclusive lock auf der Sache.

Exclusive locks können nur dann genommen werden, wenn keiner irgendein lock hat.

Two Phase Locking (2PL) #

Zwei Phasen:

• Wachstumsphase

• Schrumpfphase

  

Alle Daten die gelesen oder geschrieben werden, werden in der Wachstumsphase gelockt von der Transaktion (wenn schon gelockt dann warten). Sie werden dann in der Schrumpfungsphase wieder freigegeben.

Strenges Two Phase Locking (S2PL) #

• 2PL schließt cascading aborts nicht aus.

• S2PL schließt casscading aborts aus.

• Alle sperren werden bis zum Ende gehalten und gleichzeitig freigegeben.

  

Erkennung von Deadlocks #

Wartegraph #

Jede Transaktion is ein Konten; Kanten entstehen duch die “wartet auf”-Beziehung. Deadlocks sind vorhanden wenn der Wartegraph Kreise enthält.

Kann erkannt werden zb durch Tiefensuche im Graph.

Vermeidung von Deadlocks #

Preclaiming #

Alle locks werden gleich am Anfang genommen.

Transaktions-Zeitstempelbasiert #

Wound-Wait #

• will das Lock nehmen, das von gehalten wird.
• Wenn älter als ist, wird abortet. Der ältere killt den jüngeren
• Wenn älter als ist, wartet bis fertig ist. Der jüngere wartet

Wait-Die #

• will das Lock nehmen, das von gehalten wird.
• Wenn älter als ist, wartet bis fertig ist. Der ältere wartet
• Wenn älter als ist, wird abortet. Der ältere killt den jüngeren

Multi-Granularity Locking (MGL) #

“Hierarchisches locking”

• Zusätzliche Sperrmodi (zu: no lock, shared, exclusive):
  • IS: intention share: Weiter unten ist ein shared lock beabsichtigt
  • IX: intention exclusive: weiter unten ist ein exclusive lock beabsichtigt

• Deadlocks trotzdem möglich

Vermeidung des Phantomproblems #

Man sperrt nicht nur Tupel selbst, sondern zb auch den bereich im Index (B-Baum) der die Tupen enthält damit in der Zeit nicht eingefügt oder gelöscht werden kann.

Datum-Zeitstempelbasierte Synchronisation #

Jedes Datum hat einen readTS und writeTS Zeitstempel der jüngsten Transaktion der die Daten gelesen / geschrieben hat.

Optimistische Synchronisation #

1. Lesephase :: Alle Schreiboperationen werden auf einer lokalen kopie ausgeführt
2. Validierungsphase :: Es wird entschieden ob die Transaktion im konflikt mit anderen Transaktionen steht.
3. Schreibphase :: Wenn die validierung positiv verlaufen ist, werden die Änderungen in die Datenbank eingebracht.

Validierung bei Optimistischer Synchonisation #

Die Validierung einer Transaktion ist erfolgreich, falls für alle früher validierten Transaktionen eins der beiden gilt:

1. war vor beginn von schon abgeschlossen. kann gar nicht in Konflikt mit gekommen sein.
2. . hat nichts geschrieben was gelesen hat

Validierung bei Snapshot Isolation #

Gleich wie bei Validierung bei Optimistischer Synchonisation : Wenn vor validiert wurde und schon beendet war bevor bekonnen hat, kann nicht in Konflikt mit gekommen sein.

Ansonsten muss gelten: . hat nichts geschrieben was überschrieben hat