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.

2-Phasen-Sperrprotokoll

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

Tabelle 13.11: Beispiel für 2PL-Protokoll