Bei der sperrbasierten Synchronisation wird während des laufenden Betriebs
sichergestellt, daß die resultierende Historie serialisierbar bleibt. Dies
geschieht durch die Vergabe einer
(englisch:
).
Je nach Operation (read oder write) unterscheiden wir zwei
Sperrmodi:
- S (shared, read lock, Lesesperre):
Wenn Transaktion
eine S-Sperre für Datum A besitzt, kann
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).
Tabelle 13.10: Kompatibilitätsmatrix
Folgendes Zwei-Phasen-Sperrprotokoll (
,
) garantiert die
Serialisierbarkeit:
- Jedes Objekt muß vor der Benutzung gesperrt werden.
- Eine Transaktion fordert eine Sperre, die sie schon besitzt, nicht erneut
an.
- Eine Transaktion respektiert vorhandene Sperren gemäß der
Verträglichkeitsmatrix und wird ggf. in eine Warteschlange eingereiht.
- Jede Transaktion durchläuft eine
(nur Sperren anfordern)
und dann eine
(nur Sperren freigeben).
- 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 |
 |
 |
Bemerkung |
1. |
BOT |
|
|
2. |
lockX( ) |
|
|
3. |
read( ) |
|
|
4. |
write( ) |
|
|
5. |
|
BOT |
|
6. |
|
lockS( ) |
muß warten |
7. |
lockX( ) |
|
|
8. |
read( ) |
|
|
9. |
unlockX( ) |
|
wecken |
10. |
|
read( ) |
|
11. |
|
lockS(B) |
muß warten |
12. |
write(B) |
|
|
13. |
unlockX( ) |
|
wecken |
14. |
|
read( ) |
|
15. |
commit |
|
|
16. |
|
unlockS( ) |
|
17. |
|
unlockS( ) |
|
18. |
|
commit |
|
Tabelle 13.11: Beispiel für 2PL-Protokoll