Das R/3-Sperrkonzept
Warum muß gesperrt werden?
In einem Reisebüro soll z.B. eine Flugreservierung durchgeführt werden. Der Kunde eines Reisebüros möchte an einem bestimmten Tag mit einer bestimmten Fluggesellschaft an einen vorgegebenen Ort. Die Buchung darf nur dann vorgenommen werden, wenn die Anzahl der freien Plätze für diesen Flug noch ausreicht. Damit es zu keiner Überbuchung kommt, muß die diesem Flug entsprechende Zeile der vorgesehenen Datenbanktabelle gegen Zugriffe durch andere Transaktionen mit einer Sperre geschützt werden. Dadurch wird sichergestellt, daß die Abfrage nach der Zahl der freien Plätze, das Hinzufügen der Flugbuchung und die Änderung der Anzahl der Plätze ungestört von anderen Transaktionen erfolgen können.
Sperrmechanismen des Datenbanksystems
Das Datenbank-System verhängt automatisch Datenbanksperren, wenn Änderungsanweisungen (INSERT, UPDATE, MODIFY, DELETE) von einem Programm an die Datenbank gesendet werden. Datenbanksperren sind physische Sperren des Datenbank-Systems für die Datensätze, die von den Änderungsanweisungen angesprochen werden. Es können nur bestehende Datensätze gesperrt werden, da die Sperren durch explizite Sperrvermerke bei den geänderten Datensätzen realisiert werden. Die Sperrvermerke werden automatisch mit jedem Datenbank-Commit gelöscht. Datenbanksperren sind daher nie länger als für nur eine Datenbank-LUW verfügbar. Das bedeutet, daß in der R/3-Anwendungsprogrammierung Datenbanksperren maximal für die Dauer eines Dialogschritts bestehen können.
Die physischen Sperrmechanismen des Datenbank-Systems sind für die R/3-spezifischen Belange nicht ausreichend. Die R/3-Sperren sollten während der Dauer von SAP-LUWs bestehen und somit mehrere Dialogschritte überleben. Weiterhin müssen sie von unterschiedlichen Workprozessen und eventuell von wechselnden Applikationsservern bearbeitet werden können. Jede Sperre muß also nicht nur für den Applikations-Server gelten, der die sperrende Transaktion durchführt, sondern für alle installierten Server des R/3-Systems.
SAP-Sperren
Zur Unterstützung des SAP-LUW-Konzepts, d.h. der Durchführung gebündelter Datenbankänderungen in einer einzigen Datenbank-LUW, bietet das SAP-System einen von den Datenbanksperren völlig unabhängigen Sperrmechanismus an, der es erlaubt, Sperren über mehrere Dialogschritte aufrecht zu erhalten. Diese Sperren nennen wir SAP-Sperren.
Eine vollständige Dokumentation zu SAP-Sperren findet sich unter
Das R/3 Sperrkonzept. Hier erfolgt eine Kurzeinführung im Rahmen der ABAP-Programmierung.Die Grundlage für das SAP-Sperrkonzept sind die sogenannten Sperrobjekte. Sperrobjekte ermöglichen das Verhängen von SAP-Sperren über ganze Anwendungsobjekte. Unter Anwendungsobjekten verstehen wir einen einzelnen bzw. mehrere Datensätze einer Datenbanktabelle oder mehrere Datensätze, die über verschiedene durch Fremdschlüsselbeziehungen verknüpfte Datenbanktabellen verteilt sind.
Vor dem Verhängen einer SAP-Sperre in einem ABAP-Programm, muß zunächst ein Sperrobjekt mit dem Dictionary-Werkzeug der ABAP Workbench angelegt werden. In einem Sperrobjekt sind die Datenbanktabellen und ihre Schlüsselfelder angegeben, für die eine gemeinsame Sperre verhängt werden soll. Beim Anlegen eines Sperrobjekts werden automatisch zwei Funktionsbausteine mit den Namen
ENQUEUE_Name des Sperrobjekts und DEQUEUE_Name des Sperrobjekts erzeugt. Mit diesen Funktionsbausteinen kann der Programmierer SAP-Sperren in einem ABAP-Programm explizit setzen bzw. freigeben, indem er diese Bausteine mit CALL FUNCTION aufruft.
Vergleichen Sie hierzu den Abschnitt
Beispieltransaktion für SAP-Sperren.Die Ausführung dieser Funktionsbausteine erfolgt in einem speziellen Enqueue-Workprozess. In einem R/3-System gibt es maximal einen Applikationsserver mit Enqueue-Workprozessen. Dieser Applikationsserver verwaltet in seinem Shared Memory eine zentrale Sperrtabelle für das gesamte R/3-System.
Der Enqueue-Funktionsbaustein verhängt SAP-Sperren durch das Setzen von Einträgen in dieserr zentralen Sperrtabelle. Falls die Sperre nicht gesetzt werden kann, da das Anwendungsobjekt oder Teile davon schon gesperrt sind, unterrichtet der Funktionsbaustein den Benutzer. Die folgende Abbildung zeigt die beim Sperren beteiligten Komponenten des R/3-Basis-Systems:
Der SAP-Sperrmechanismus setzt logische Sperren. Das bedeutet:
Der Sperreintrag wird ausschließlich als sogenannte Sperrbedingung in der zentralen Sperrtabelle des R/3-Systems eingetragen. Die Formulierung der Sperrbedingung erfolgt durch die Übergabe von Werten für die Primärschlüsselfelder der im Sperrobjekt zusammengefaßten Tabellen an den Enqueue-Funktionsbaustein. Er ist unabhängig von Datenbank-LUWs und wird entweder implizit durch Beendigung einer Verbuchung oder einer SAP-Transaktion oder explizit durch einen Dequeue-Funktionsbaustein aufgehoben. Der genaue Zeitpunkt, zu dem Sperren bei einer Verbuchung aufgehoben werden, kann über einen speziellen Parameter des Verbuchungs-Funktionsbausteins festgelegt werden.
Ein Sperreintrag kann in der Sperrtabelle vorsorglich gesetzt werden, zum Beispiel für einen Datensatz, der erst während der Verbuchung am Ende der SAP-LUW in eine Datenbanktabelle geschrieben wird.
Da keine physischen Sperren in den Datenbanktabellen gesetzt werden, müssen alle Programme, die auf die gleichen Anwendungsobjekte zugreifen, explizit die Sperrtabelle nach eventuellen Sperren abfragen. Es gibt keinen Mechanismus, der eine Umgehung der Sperren in der Sperrtabelle automatisch verhindert.
Sperrmodi
Das SAP-System kennt zwei Sperrmodi:
Die Lesesperre dient dem ungestörten Lesen von Anwendungsobjekten. Eine Lesesperre verhindert, daß während der Dauer der Sperre von anderen Programmen eine Schreibsperre zum Ändern des Anwendungsobjekts gesetzt wird. Das gleichzeitige Setzen weiterer Lesesperren ist dagegen erlaubt.
Die Schreibsperre dient dem ungestörten Ändern von Anwendungsobjekten. Eine Schreibsperre sperrt Anwendungsobjekte exklusiv für das sperrende Programm. Andere Programme können weder Lese- noch Schreibsperren für die gleichen Anwendungsobjekte verhängen.
Sperrdauern
Beim Setzen von Sperren sollte bedacht werden, daß eine längere Sperrdauer für ein Objekt auch eine geringere Verfügbarkeit des Objekts für andere Transaktionen bedeutet. Ob dies in Kauf genommen werden kann, hängt immer von der jeweiligen Aufgabenstellung ab.
Insbesondere das unbedachte Verhängen von zu vielen Lesesperren kann das Arbeiten mit Datenbanktabellen stark beeinträchtigen. Wenn viele parallel ablaufende Programme Lesesperren für das gleiche Anwendungsobjekt in einem R/3-System setzen, kann dies einen ändernden Zugriff fast unmöglich machen, da das ändernde Programm kein Zeitfenster findet, in dem die Schreibsperre gesetzt werden kann. Umgekehrt verhindert eine letztendlich verhängte Schreibsperre dann den lesenden Zugriff aller übrigen Programme.
Jede Sperre sollte am Ende einer SAP-LUW aufgehoben werden. Dies geschieht entweder automatisch während der Verbuchung oder explizit durch den Aufruf des entsprechenden Dequeue-Funktionsbausteins. Sperren, die nicht mit einer Verbuchung verknüpft sind, werden spätestens am Ende der SAP-Transaktion aufgehoben.