Das Eigentümerkonzept 
Das Eigentümerkonzept
Zu Beginn einer SAP-Transaktion werden immer zwei Eigentümer angelegt, die Sperren anfordern können.
Ein Eigentümer wird durch seine Eigentümer-Id bestimmt, die im Kapitel
Die Sperrtabelle beschrieben ist.Eine Sperre kann einen oder zwei Eigentümer haben. Dies wird vom ABAP-Programmierer mit dem
_SCOPE-Parameter (siehe unten) bestimmt.Das folgende Diagramm zeigt beispielhaft eine SAP-LUW aus Sicht der Sperren.
Mit Beginn der Dialogtransaktion werden vom System zwei Sperreigentümer angelegt: der Dialogeigentümer Eigentümer_1 und der Verbuchungseigentümer Eigentümer_2.
Dann fordert im Laufe der Transaktion der Eigentümer_1 eine Sperre an, etwas später Eigentümer_2. Beim Aufruf des Verbuchers (siehe dazu
Funktionsweise der Verbuchung) wird die Sperre mit Eigentümer_2 an den Verbucher vererbt. Ein Verbuchungs-Workprozeß wird wie ein Dialogworkprozeß mit zwei Eigentümern gestartet und hat dann bis zum Ende der Verbuchung drei Eigentümer. Spätestens am Ende der Verbuchung werden alle Sperren mit einem impliziten DEQUEUE_ALL freigegeben.
Der _SCOPE-Parameter
Dieser Parameter dient dem Anwendungsprogrammierer dazu, festzulegen, welchem der zwei Eigentümer die Sperre wirklich gehören soll.
_SCOPE kann die Werte 1,2 oder 3 annehmen:|
_SCOPE = 1 |
Die Sperre gehört nur Eigentümer_1, bleibt also nur in der Dialogtransaktion bestehen. Die Sperre wird durch den DEQUEUE-Aufruf oder durch das Ende der Transaktion aufgehoben, nicht durch COMMIT WORK oder ROLLBACK WORK. |
|
_SCOPE = 2 |
Die Sperre gehört nur Eigentümer_2, wird also an die Verbuchung vererbt, wenn CALL FUNCTION ‘…‘ IN UPDATE TASK und COMMIT WORK aufgerufen wird. Sie wird aufgehoben, wenn die Verbuchungstransaktion abgeschlossen ist. Bevor die Sperre an die Verbuchung übergeben wird, kann sie mit ROLLBACK WORK aufgehoben werden. COMMIT WORK hat keinen Einfluss, solange nicht CALL FUNCTION ‘…‘ IN UPDATE TASK aufgerufen wurde. |
|
_SCOPE = 3 |
Die Sperre gehört Eigentümer_1 und Eigentümer_2, kombiniert also die beiden Verhaltensweisen. Sie wird aufgehoben, wenn der letzte der beiden Eigentümer die Sperre freigibt. |
Weitere Informationen dazu finden Sie unter
Funktionsbausteine für Sperranforderungen.
Die folgende Abbildung zeigt die Sperren im Verlauf einer SAP-LUW im Zusammenhang mit dem
_SCOPE-Parameter. Es wird dargestellt, wie lange die SAP-Sperren aktiv sind (das sind nicht die tatsächlichen Datenbanksperren, wie unter Funktionsweise des SAP-Sperrkonzepts beschrieben).Die Sperre besteht solange, bis entweder der entsprechende
DEQUEUE-Funktionsbaustein aufgerufen wird oder (wie im Bild dargestellt) die Transaktion mit einem impliziten DEQUEUE_ALL endet.
In diesem Beispiel wird also im Laufe der Transaktion das Sperrobjekt A (das der Programmierer vorher im ABAP Dictionary
angelegt hat) durch den Funktionsaufruf CALL FUNCTION 'ENQUEUE_A' gesperrt. Durch Setzen des _SCOPE-Parameters auf 1 wird festgelegt, daß die Sperre A nicht an den Verbucher weitergegeben wird (sie gehört nur dem Dialogeigentümer E_1) und damit mit dem Funktionsaufruf DEQUEUE_A oder spätestens mit dem Ende der Dialogtransaktion aufgehoben wird.
Später werden die Sperre B, die E_2 (dem Verbuchungseigentümer) gehört (
_SCOPE=2) und die Sperre C, die zwei Eigentümer hat (_SCOPE=3), angefordert. Mit dem Aufruf CALL FUNCTION '…' IN UPDATE TASK wird einVerbuchungsauftrag generiert. Beim COMMIT WORK wird der Verbucher aufgerufen, der die Sperren und den Verbuchungseigentümer der Sperren B und C erbt. Mit dem Ende der Verbuchung werden diese Sperren freigegeben. Es ist aber möglich, daß die Sperre C des Dialogeigentümers noch länger besteht (je nach Programmierung der Transaktion).
Dia Dialogsperren A und C bestehen noch bis zum Ende der Dialogtransaktion.
Wird eine Sperre mit
_SCOPE=2 gesetzt, und der COMMIT WORK-Aufruf erfolgt vor dem CALL FUNCTION ‘…‘ IN UPDATE TASK, so bleibt die Sperre bis zu diesem Zeitpunkt als Dialogsperre (schwarz in der Übersicht der Transaktion SM12) stehen. Sie konnte ja noch nicht an einen Verbuchungs-Workprozess übergeben werden.Erst der Aufruf von
CALL FUNCTION ‘…‘ IN UPDATE TASK und das COMMIT WORK zu einem späteren Zeitpunkt bewirkt, dass die Sperre an den Verbuchungsprozess übergeben wird. Dann wird sie in der Übersicht der SM12 blau angezeigt.Siehe auch:
Die Sperrtabelle Kollisionen von Sperren Kumulation von Sperren