8 Synchronisation in Verteilten Datenbanksystemen

8.1 Sperrverfahren in Verteilten DBS

Sperrverfahren sind dadurch gekennzeichnet, daß das DBVS vor dem Zugriff auf ein Objekt für die betreffende Transaktion eine Sperre erwirbt, deren Modus dem Zugriffswunsch entspricht. Zur Sicherstellung der Serialisierbarkeit ist dabei i.a. ein sogenanntes strikt zweiphasiges Sperrprotokoll erforderlich, bei dem sämtliche Sperren bis zum Transaktionsende gehalten werden (zweite Commit-Phase) [Gr78]. Im einfachsten Fall wird nur zwischen Lese- und Schreibsperren unterschieden (RX-Sperrverfahren). Dabei sind Lese- oder R-Sperren (read locks, shared locks) miteinander verträglich, während Schreib- oder X-Sperren (exclusive locks) weder mit sich selbst noch mit Lesesperren kompatibel sind. So können bei gesetzter R-Sperre auf ein Objekt weitere Leseanforderungen gewährt werden, jedoch keine X-Sperren; bei gesetzter X-Sperre sind alle weiteren Sperranforderungen abzulehnen. Ein Sperrkonflikt führt zur Blockierung der Transaktion, deren Sperranforderung den Konflikt verursacht hat; die Aktivierung der wartenden Transaktionen ist möglich, sobald die unverträglichen Sperren freigegeben sind.

Beispiel 8-2

Für den Schedule in Abb. 8-1a tritt mit einem RX-Protokoll ein Sperrkonflikt auf: für die Lesesperre von T2 auf Objekt y ergibt sich ein Konflikt aufgrund der zuvor gewährten X-Sperre für T1. T2 wird nach Beendigung und Freigabe der Sperren von T1 fortgesetzt. Dagegen verursacht der Lesezugriff von T1 auf x keinen Konflikt, da zu diesem Zeitpunkt T3 bereits beendet ist. Als Serialisierungsreihenfolge ergibt sich T3 < T1 < T2.

8.1.1 - Zentrales Sperrprotokoll
8.1.2 - Verteilte Sperrverfahren