Shared Objects - Sperren 

Bei jedem Zugriff auf eine Gebietsinstanzversion, das heißt bei jedem Anbinden eines Gebietshandles wird eine Sperre auf die Gebietsinstanzversion gesetzt. Die Sperre besteht, solange ein Gebietshandle an eine Gebietsinstanzversion angebunden ist und weist eventuell den Versuch andere Gebietshandles an die Gebietsinstanz anzubinden ab. Solange keine Sperre gesetzt ist, hat ein Programm keinen Zugriff auf Gebietsinstanzen.

Lesesperren

Eine Lesesperre wird gesetzt, wenn ein Gebietshandle mit  der Methode ATTACH_FOR_READ an eine Gebietsinstanzversion angebunden wird.

Innerhalb eines internen Modus kann es maximal eine Lesesperre auf eine Gebietsinstanz geben. Modusübergreifend kann es mehrere Lesesperren auf einer Gebietsinstanzversion geben.

Nachdem in einem Programm eine Lesesperre gesetzt wurde, kann dort bis zur Ausführung der Methode DETACH lesend auf die entsprechende Gebietsinstanzversion und ihre Objekte zugegriffen werden.

Wenn eine Lesesperre immer direkt vor einem Zugriff gesetzt und danach wieder gelöst wird, ist zu beachten, dass bei einem folgenden Zugriff eventuell nicht auf die gleiche Version der Gebietsinstanz zugegriffen wird. Eine Lesesperre wird immer auf die aktive Gebietsinstanzversion gesetzt.

Änderungssperren

Ein Änderungssperre ist entweder eine Schreib- oder eine Aktualisierungssperre. Eine Schreibsperre wird gesetzt, wenn ein Gebietshandle mit der Methode ATTACH_FOR_WRITE, eine Aktualisierungssperre, wenn ein Gebietshandle mit der Methode ATTACH_FOR_UPDATE an eine Gebietsinstanzversion angebunden wird.

Auf einen Applikationsserver kann es maximal eine Änderungssperre auf eine Gebietsinstanz geben. Eine Änderungssperre sperrt eine Gebietsinstanzversion exklusiv, d.h. es sind auf dieser Version keine parallelen Lesesperren möglich. Parallele Lesezugriffe auf die gleiche Gebietsinstanz sind möglich, wenn die Versionierung der Gebietsinstanzen aktiviert ist.

Nachdem in einem Programm eine Änderungssperre gesetzt wurde, kann dort bis zur Ausführung der Methode DETACH_COMMIT oder DETACH_ROLLBACK lesend und ändernd auf die Gebietsinstanzversion und die Objekte der Gebietsinstanzversion zugegriffen werden. Beim Schreibzugriff wird eine neue, leere Gebietsinstanzversion angelegt. Beim Aktualisierungszugriff wird

●      bei Gebieten ohne Versionierung die bestehende aktive Version zum Ändern angebunden und

●      bei Gebieten mit Versionierung eine Kopie der aktiven Gebietsinstanzversion erzeugt und zum Ändern angebunden.

Aufheben von Sperren

Ausser mit der Methode DETACH werden Lesesperren auch automatisch bei Beendigung eines internen Modus aufgehoben.

Änderungssperren müssen immer explizit mit DETACH_COMMIT oder DETACH_ROLLBACK aufgehoben werden. In folgenden Situationen darf es keine Änderungssperre auf eine Gebietsinstanzversion geben, da es ansonsten zum Laufzeitfehler SYSTEM_SHM_CHANGE_LOCK_ACTIVE kommt und alle Änderungen verworfen werden:

●      Schließen eines internen Modus außer mit der Anweisung LEAVE TRANSACTION (bzw. Funktion „/n“). Bei der Anweisung LEAVE TRANSACTION werden alle Änderungssperren mit der Methode DETACH_ROLLBACK freigegeben.

●      Datenbank-Commit im Fall von transaktionalen Gebieten.

●      Programmaufrufe mit SUBMIT AND RETURN, CALL TRANSACTION und CALL DIALOG im Fall von transaktionalen Gebieten.

Wenn alle Referenzvariablen auf ein Gebietshandle initialisiert und das Gebietshandle danach vom Garbage Collector gelöscht wird, während es eine Sperre hält, wird die Sperre nicht mit gelöscht. Auf die Gebietsinstanzversion kann weiterhin zugegriffen werden, wobei Änderungssperren aber nicht mehr freigegeben werden können und es zwangsläufig zu obigem Laufzeitfehler kommt.

Bei einem transaktionalen Gebiet ist zu beachten, dass vor dem Schließen eines internen Modus oder einem Programmaufruf (SUBMIT, CALL TRANSACTION, LEAVE TO TRANSACTION oder CALL DIALOG) eine mit der Methode DETACH_COMMIT aufgehobene Änderungssperre erst mit einem Datenbank-Commit endgültig freigegeben werden muss.