Beispiel: Verwendung der Prüfungs-Sperrmodi 
Neben den Sperrmodi S, E, X und O bzw. R, bei denen nach erfolgreicher Kollisionsprüfung die entsprechende Sperre gesetzt wird, gibt es die Modi U,V, W und C. Diese dienen dazu, lediglich die Kollisionsprüfung durchzuführen, aber keine Sperre zu setzen. Der Aufrufer bekommt also das Ergebnis, ob er eine Sperre des entsprechenden Typs bekommen hätte.
Hier gilt folgende Entsprechung:
Sperrmodus |
Kollisionsprüfung für Sperrtyp |
|---|---|
U |
X |
V |
E |
W |
S |
C |
R (Umwandlung einer optimistischen Sperre in eine E-Sperre) Weitere Informationen: Optimistische Sperren |
Vorgehensweise
Sie können diese Sperrmodi verwenden, um einen Schutz bei Lesesperren zu implementieren, der verhindert, dass ein Schreiber „verhungert“, d.h. nie seine Schreibsperre setzen kann, weil immer mindestens ein Leser gesperrt hat.
Im folgenden Beispiel seien xxx und yyy verschiedene Elemantarsperren, die sich auf die gleichen Daten beziehen. Dies kann durch verschiedene Datenbanktabellen mit den gleichen Feldern erreicht werden.
Dann führt der Leser folgende Operationen atomar, also in einer Sperroperation, durch:
V … yyy … ;stellt fest, ob ein Schreiber eine Sperre setzen will. Im Fall einer Kollision macht der Leser nichts weiter.Falls die V-„Sperre“ nicht kollidiert ist:
S … xxx …;sperrt das Objekt (Typ S: Lesesperre) und lässt dabei weitere Leser, aber keinen Schreiber zu.
Hinweis
Hierzu muss ein Enqueue-Funktionsbaustein verwendet werden, der beide Elementarsperren enthält. Ein solches Sperrobjekt definieren Sie in der Transaktion SE11 (bzw. SE80) aus Tabellen mit Fremdschlüsselbeziehung.
Die Sperroperationen des Schreibers sind die Folgenden (nicht atomar, sondern aufeinander folgende Sperroperationen):
E … yyy …;schließt die Tür für neue Leser und weitere Schreiber… Loop …;wartet bis der letzte Leser freigegeben hatE … xxx …setzt dann die Schreibsperre.