Sperrbasierte Synchronisation

Bei der sperrbasierten Synchronisation wird während des laufenden Betriebs sichergestellt, daß die resultierende Historie serialisierbar bleibt. Dies geschieht durch die Vergabe einer $Sperre$ (englisch: $lock$).

Je nach Operation (read oder write) unterscheiden wir zwei Sperrmodi:

• S (shared, read lock, Lesesperre):
  Wenn Transaktion $T_i$ eine S-Sperre für Datum A besitzt, kann $T_i$ read(A) ausführen. Mehrere Transaktionen können gleichzeitig eine S-Sperre auf dem selben Objekt A besitzen.
• X (exclusive, write lock, Schreibsperre):
  Ein write(A) darf nur die eine Transaktion ausführen, die eine X-Sperre auf A besitzt.

Tabelle 13.10 zeigt die Kompatibilitätsmatrix für die Situationen NL (no lock), S (read lock) und X (write lock).

	$NL$	$S$	$X$
$S$	$\surd$	$\surd$	-
$X$	$\surd$	-	-

Tabelle 13.10: Kompatibilitätsmatrix

Folgendes Zwei-Phasen-Sperrprotokoll ($two$ $phase$ $locking$, $2PL$) garantiert die Serialisierbarkeit:

1. Jedes Objekt muß vor der Benutzung gesperrt werden.
2. Eine Transaktion fordert eine Sperre, die sie schon besitzt, nicht erneut an.
3. Eine Transaktion respektiert vorhandene Sperren gemäß der Verträglichkeitsmatrix und wird ggf. in eine Warteschlange eingereiht.
4. Jede Transaktion durchläuft eine $Wachstumsphase$ (nur Sperren anfordern) und dann eine $Schrumpfungsphase$ (nur Sperren freigeben).
5. Bei Transaktionsende muß eine Transaktion alle ihre Sperren zurückgeben.

Abbildung 13.3 visualisiert den Verlauf des 2PL-Protokolls. Tabelle 13.11 zeigt eine Verzahnung zweier Transaktionen nach dem 2PL-Protokoll.

Abbildung 13.3: 2-Phasen-Sperrprotokoll

Schritt	$T_1$	$T_2$	Bemerkung
1.	BOT
2.	lockX($A$)
3.	read($A$)
4.	write($A$)
5.		BOT
6.		lockS($A$)	$T_2$ muß warten
7.	lockX($B$)
8.	read($B$)
9.	unlockX($A$)		$T_2$ wecken
10.		read($A$)
11.		lockS(B)	$T_2$ muß warten
12.	write(B)
13.	unlockX($B$)		$T_2$ wecken
14.		read($B$)
15.	commit
16.		unlockS($A$)
17.		unlockS($B$)
18.		commit

Tabelle 13.11: Beispiel für 2PL-Protokoll