Logische Sperren 

Mit logischen Sperren können einzelne Zeilen oder generische Bereiche von Datenbanktabellen gesperrt werden. Es gibt Schreibsperren und Lesesperren. Für ein Objekt kann höchstens eine Schreibsperre, aber viele Lese-Sperren gesetzt werden. Lese- und Schreibsperren schließen sich gegenseitig aus. Aus diesem Grund heißen Lesesperren auch gemeinsame Sperren und Schreibsperren auch exklusive Sperren. Im Sperrprotokoll  ist definiert, bei welcher Art des Zugriffs zu welchem Zeitpunkt Sperren gesetzt werden. Alle Anwendungen müssen sich an das für die betreffende Tabelle festgelegte Sperrprotokoll halten. Im folgenden werden zwei mögliche Sperrprotokolle diskutiert.

 

Sperrprotokoll 1:

Es werden nur Schreibsperren gesetzt. Soll ein Objekt in einer Transaktion geändert werden, fordert die Anwendung am Anfang der Transaktion eine Schreibsperre für dieses Objekt an. Ist das Objekt bereits gesperrt, kann die Anwendung nicht im Änderungsmodus, sondern nur im Anzeigemodus betrieben werden. Da keine Lesesperren gesetzt werden, können Objekte immer gelesen werden (sofern der Isolationslevel der Datenbank dies zulässt, wovon i. Allg. ausgegangen werden kann, s.o.). Dieses Sperrprotokoll garantiert die höchste Parallelität und Skalierbarkeit.

 

Sperrprotokoll  2:

Es werden Lese- und Schreibsperren gesetzt. Wird ein Objekt von der Datenbank gelesen, wird eine Lesesperre gesetzt. Soll ein Objekt geändert werden, wird eine Schreibsperren angefordert. Kann eine Schreibsperre nicht gesetzt werden, weil eine Lesesperre oder eine Schreibsperre gesetzt ist, muss sich die Anwendung entscheiden, ob sie die Transaktion abbricht oder später noch einmal versucht, die Schreibsperre zu erhalten. Die Schreibsperre kann sowohl sofort bei der Änderung des Objektes angefordert werden, als auch kurz vor dem Ende der Transaktion. Für das frühe Anfordern einer Schreibsperre spricht die Möglichkeit, den Anwender frühzeitig informieren zu können, für das späte Anfordern spricht die kürzere Zeitspanne, in der die Sperre gesetzt ist und damit eine höhere Parallelität und Skalierbarkeit, da das Setzen einer Schreibsperre das Lesen des Objektes in einer anderen Transaktion verhindert. Beim späten Anfordern einer Schreibsperre ist darauf zu achten, spätestens beim Ändern des Objektes eine Lesesperre anzufordern. Dadurch wird sichergestellt, dass das Objekt in einer anderen Transaktion nicht geändert werden kann.

Es müssen sich alle Anwendungen, die auf eine Tabelle zugreifen, an das vereinbarte Sperrprotokoll halten.

Versuchen zwei Anwendungen auf mehreren Objekten gleichzeitig in unterschiedlicher Reihenfolge Sperren zu erhalten, können sogenannte Verklemmungen auftreten. Um dies zu vermeiden, wird eine Ausnahme ausgelöst, wenn eine Sperre nicht gesetzt werden kann.