
Kollisionen von Sperren
Die Überprüfung, ob eine Sperranforderung mit einer bestehenden Sperre kollidiert, erfolgt in zwei Schritten: zuerst wird überprüft, ob die Sperranfrage mit einer Elementarsperre in der
Sperrtabelle kollidiert. Ist dies der Fall, wird überprüft, ob eine Eigentümer-Kollision vorliegt. (Derselbe Eigentümer darf ja beispielsweise eine Schreibsperre mehrmals anfordern. Dies ist unter
Kumulation von Sperren beschrieben.)Im Kollisionsfall erhält der Benutzer der Dialogtransaktion die Nachricht, daß das gewünschte Objekt gerade durch einen anderen Benutzer gesperrt ist. Bei Nicht-Dialog-Prozessen (etwa im Batch-Input) wird die Sperranforderung zu einem späteren Zeitpunkt wieder gestellt.
Kollision von Elementarsperren
Zwei Elementarsperren kollidieren, wenn alle folgenden Bedingungen erfüllt sind:
- Name
der Elementarsperre (Tabelle, in der gesperrt werden soll) ist gleich
- Sperrargument
ist gleich, genauer: die Buchstaben stimmen an jeder Position überein (der Wildcardbuchstabe, hier mit @ gekennzeichnet, ist zu allen Buchstaben gleich)
- mindestens eine Elementarsperre hat nicht den Sperrmodus S (Lesesperre)
in der folgenden Grafik sind einige Beispiele zusammengestellt, die zeigen, wann eine Sperranfrage (links) mit einer bestehenden Sperre (rechts) kollidiert.


- Schreibsperre ABCD auf Tabelle TAB1 kollidiert mit vorhandener Schreibsperre ABCD auf Tabelle TAB1
- Schreibsperre ABCD auf Tabelle TAB2 kollidiert nicht mit vorhandener Schreibsperre ABCD auf Tabelle TAB1, wird also akzeptiert, weil Sperrname verschieden
- Lesesperre ABCD auf Tabelle TAB1 kollidiert nicht mit vorhandener Lesesperre ABCD auf Tabelle TAB1, wird also akzeptiert, weil beides Lesesperren sind
- Schreibsperre ABCD auf Tabelle TAB1 kollidiert mit vorhandener Lesesperre ABCD auf Tabelle TAB1
- Schreibsperre AB@@ auf Tabelle TAB1 kollidiert mit vorhandener Schreibsperre ABCD auf Tabelle TAB1, weil @=C und @=D gilt
- Schreibsperre ABCD auf Tabelle TAB1 kollidiert mit vorhandener generischer Schreibsperre AB@@ auf Tabelle TAB1, weil C=@ und D=@ gilt
- Schreibsperre @@CD auf Tabelle TAB1 kollidiert mit vorhandener Schreibsperre AB@@ auf Tabelle TAB1, weil @=A und @=B und C=@ und D=@ gilt
- Schreibsperre @@CDE auf Tabelle TAB1 kollidiert nicht mit vorhandener Schreibsperre AB@@ auf Tabelle TAB1, weil der 5. Buchstabe nicht übereinstimmt (E ungleich _)
Kollidieren die Elementarsperren nicht, so wird die Sperranfrage als neuer Eintrag in die Sperrtabelle aufgenommen. Kollidieren die Elementarsperren, so wird auf eine Eigentümerkollision geprüft (im folgenden beschrieben).
Eigentümerkollision
Im Fall einer Kollision von Elementarsperren erfolgt die Entscheidung, ob die Sperranfrage angenommen oder abgewiesen wird, also aufgrund der Eigentümer, die zu den Sperren gehören (siehe
Das Eigentümerkonzept).Eine Eigentümerkollision liegt vor, wenn bei vorliegender Elementarsperrenkollision eine der folgenden Bedingungen zutrifft:
- mindestens ein Eigentümer unterscheidet sich
- die Eigentümer sind gleich, aber mindestens eine Sperre hat den Modus X (erweiterte Schreibsperre, keine Kumulation, siehe dazu
Sperrmodus)
Die folgende Grafik zeigt beispielhaft einige Situationen: Hierbei ist O_x ein Eigentümer ungleich O_1 und O_2.


- Kein Eigentümer unterscheidet sich, keine Sperre im Modus X, daher keine Kollision
- Eigentümer_2 unterscheidet sich, also Kollision
- Eigentümer_1 unterscheidet sich, also Kollision
- Eigentümer_1 ist gleich, aber Eigentümer_2 unterscheidet sich, also Kollision
- Kein Eigentümer unterscheidet sich, keine Sperre im Modus X, daher keine Kollision
- Kein Eigentümer unterscheidet sich, aber die Sperranfrage hat den Modus X, daher Kollision
- Kein Eigentümer unterscheidet sich, aber die bestehende Sperre hat den Modus X, daher Kollision
- Eigentümer_1 unterscheidet sich, also Kollision
- Eigentümer_2 unterscheidet sich, also Kollision
Eigentümerkollision impliziert also Elementarsperrenkollision. Nur wenn eine Eigentümerkollision vorliegt, wird die Sperranfrage zurückgewiesen!
Siehe auch:
Kumulation von Sperren
Das Eigentümerkonzept