Anfang des InhaltsbereichsHintergrunddokumentationKollisionen von Sperren Dokument im Navigationsbaum lokalisieren

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:

in der folgenden Grafik sind einige Beispiele zusammengestellt, die zeigen, wann eine Sperranfrage (links) mit einer bestehenden Sperre (rechts) kollidiert.

Beispiel

Diese Grafik wird im zugehörigen Text erklärt

    1. Schreibsperre ABCD auf Tabelle TAB1 kollidiert mit vorhandener Schreibsperre ABCD auf Tabelle TAB1
    2. Schreibsperre ABCD auf Tabelle TAB2 kollidiert nicht mit vorhandener Schreibsperre ABCD auf Tabelle TAB1, wird also akzeptiert, weil Sperrname verschieden
    3. Lesesperre ABCD auf Tabelle TAB1 kollidiert nicht mit vorhandener Lesesperre ABCD auf Tabelle TAB1, wird also akzeptiert, weil beides Lesesperren sind
    4. Schreibsperre ABCD auf Tabelle TAB1 kollidiert mit vorhandener Lesesperre ABCD auf Tabelle TAB1
    5. Schreibsperre AB@@ auf Tabelle TAB1 kollidiert mit vorhandener Schreibsperre ABCD auf Tabelle TAB1, weil @=C und @=D gilt
    6. Schreibsperre ABCD auf Tabelle TAB1 kollidiert mit vorhandener generischer Schreibsperre AB@@ auf Tabelle TAB1, weil C=@ und D=@ gilt
    7. Schreibsperre @@CD auf Tabelle TAB1 kollidiert mit vorhandener Schreibsperre AB@@ auf Tabelle TAB1, weil @=A und @=B und C=@ und D=@ gilt
    8. 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:

Die folgende Grafik zeigt beispielhaft einige Situationen: Hierbei ist O_x ein Eigentümer ungleich O_1 und O_2.

Beispiel

Diese Grafik wird im zugehörigen Text erklärt

    1. Kein Eigentümer unterscheidet sich, keine Sperre im Modus X, daher keine Kollision
    2. Eigentümer_2 unterscheidet sich, also Kollision
    3. Eigentümer_1 unterscheidet sich, also Kollision
    4. Eigentümer_1 ist gleich, aber Eigentümer_2 unterscheidet sich, also Kollision
    5. Kein Eigentümer unterscheidet sich, keine Sperre im Modus X, daher keine Kollision
    6. Kein Eigentümer unterscheidet sich, aber die Sperranfrage hat den Modus X, daher Kollision
    7. Kein Eigentümer unterscheidet sich, aber die bestehende Sperre hat den Modus X, daher Kollision
    8. Eigentümer_1 unterscheidet sich, also Kollision
    9. 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

 

 

Ende des Inhaltsbereichs