Kontakt

Ansicht
Dokumentation

ABENBDL_LOCKING - BDL LOCKING

ABENBDL_LOCKING - BDL LOCKING

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

- Sperren

Deklaration auf Entitätsebene

... lock master $[unmanaged$]
  $| lock dependent by _Assoc

Für eine Aktion verwendbarer Syntaxzusatz

... lock:none

Varianten:

1. ... lock master [unmanaged]

2. ... lock dependent by _Assoc

3. ... lock:none

Wirkung

Hiermit wird ein RAP-Sperrmechanismus für eine RAP-BO-Entität angegeben. Mit dem RAP-Sperrmechanismus wird der gleichzeitige modifizierende Zugriff auf die Daten der Datenbank durch mehrere Benutzer verhindert (das pessimistische Concurrency-Control). Bei einer Sperranforderung für eine spezifische Entitätsinstanz werden sein Sperr-Master und alle sperrabhängige Entitätsinstanzen für die Bearbeitung durch einen anderen Benutzer gesperrt. D.h. Beim Erhalten einer Sperranforderung bei einem Knoten wird die ganze BO-Instanz gesperrt.

Lock-Master-Entitäten werden nach jeder Sperranforderung einer ihrer sperrabhängigen Entitäten gesperrt. In einem nicht verwalteten RAP-BO muss die RAP-Behandlermethode FOR LOCK für Sperr-Master-Entitäten implementiert werden. Bei sperrabhängigen Entitäten wird jede Sperranforderung an die Sperr-Master-Entität delegiert. Zur Zeit können nur Wurzelentitäten als Sperr-Master-Entitäten definiert werden.

Setzen von Sperren

Wenn eine Sperre für eine RAP-BO-Entität definiert wird, werden die jeweiligen Entitätsinstanzen während der Laufzeit folgender modifizierender Operationen implizit gesperrt:

  • create: In einem verwalteten RAP-BO werden die neu angelegten Schlüsselwerte (wenn vorhanden) der Instanzen während der anlegenden Operation in die globale Sperrtabelle geschrieben. Dies gehört zu einer Eindeutigkeitsprüfung, die durch das RAP-Framework automatisch und implizit durchgeführt wird. In einem nicht verwalteten RAP-BO findet keine Eindeutigkeitsprüfung statt und es werden keine Schlüsselwerte in die globale Sperrtabelle geschrieben. Weitere Informationen finden Sie im Entwicklungsleitfaden für das ABAP-RESTful-Anwendungsprogrammiermodell, Abschnitt Uniqueness Check.

Verwaltetes RAP-BO

In einem verwalteten RAP-BO muss jede Entität entweder als lock master oder als lock dependent definiert sein. Der Sperrmechanismus wird durch das RAP-Framework behandelt.

Nicht verwaltetes RAP-BO

In einem nicht verwalteten RAP-BO ist die Definition der Entitäten entweder als lock master oder als lock dependent, erzwungen wird dies aber nur im strikten BDEF-Modus. Die Sperre muss vom Anwendungsentwickler im ABAP-Behavior-Pool in der RAP-Behandlermethode FOR LOCK implementiert werden. Dies kann beispielsweise über DDIC- Sperrobjekte erfolgen.

Entwurfsfähige RAP-BO

Bei entwurfsfähigen BOs muss das Sperren auch berücksichtigt werden. Direkt nach dem Anlegen einer Entwurfsinstanz für eine existierende aktive Instanz erhält die aktive Instanz eine Schreibsperre und kann nicht durch einen anderen Benutzer modifiziert werden. Diese Schreibsperre wird auch bei einer abgebrochenen ABAP-Sitzung für eine bestimmte Zeit erhalten.. Die Dauer der Schreibsperre ist konfigurierbar. Nach Ablauf der Schreibsperre nach dieser Dauer beginnt die optimistische Sperrphase. Während der optimistischen Sperrphase kann ein Entwurf bei nicht geänderter aktiver Instanz wiederaufgenommen werden, die Schreibsperre besteht aber nicht mehr.

Projektions-BO

In einem Projektions-Business-Objekt wird der für die Basis-BO definierte und implementierte Sperrmechanismus automatisch wiederverwendet und muss nicht explizit definiert werden. Detaillierte Informationen finden Sie unter CDS BDL - Entitätsverhaltensmerkmalen, Projektions-BDEF.

Entwicklungsleitfaden für das ABAP-RESTful-Anwendungsprogrammiermodell, Abschnitt Pessimistic Concurrency Control (Locking).

Hinweise

  • Wenn der strikte BDEF-Modus eingeschaltet ist, ist die Markierung von jeder Entität als entweder lock master oder als lock dependent obligatorisch, auch in nicht verwalteten RAP-BOs.
  • Sperren werden in einer globalen Sperrtabelle verwaltet (Administration durch Transaktion SM12)

Beispiel - Verwaltet

Im folgenden Beispiel wird eine auf der CDS-Wurzel-View-Entität DEMO_SALES_CDS_BUPA_2 basierte verwaltete BDEF gezeigt. Die Wurzelentität wird als Sperr-Master-Entität und die untergeordneten Entität als sperrabhängige Entität definiert Die Assoziation association _Address { } wird im Entitätsverhaltensrumpf der untergeordneten Entität definiert und damit wird das Delegieren von Sperranforderungen an die untergeordnete Entität an die Sperr-Master-Entität gewährleistet.

Das Programm DEMO_SALES_RAP_LOCK greift über EML auf das Business-Objekt zu und legt zwei BO-Instanzen an.

Quelltextausschnitt:

Im folgenden Bild wird die globale Sperrtabelle (Transaktion SM12) während der Transaktion und vor Ausführung der COMMIT ENTITIES-Anweisung gezeigt. Die Schlüsselwerte beider neu angelegter Entitäten werden hier als Teil der Eindeutigkeitsprüfung aufgeführt. Nach Ausführung der COMMIT ENTITIES-Anweisung werden beide Einträge automatisch gelöscht.

IMAGE @@ABDOC_lock_table.png@@1092@@168@@

Beispiel - Nicht verwaltet

Im folgenden Beispiel wird eine auf der CDS-Wurzel-View-Entität DEMO_RAP_UNMANAGED_LOCKING basierte nicht verwaltete BDEF gezeigt. Die Wurzelentität wird als Sperr-Master-Entität definiert.

Die lock-Methode wird wie unten gezeigt im ABAP-Behavior-Pool implementiert. Mit dem Sperrobjekt ERAPLOCK wird der Zugriff auf die persistente Datenbanktabelle gesteuert.

Mit dem Programm DEMO_RAP_UNMANAGED_LOCK wird über EML auf ein Business-Objekt aufgegriffen und folgende Schritte ausgeführt:

  • es werden zwei Entitätsinstanzen angelegt
  • es wird eine der Instanzen aktualisiert.
  • es werden beide Instanzen gelöscht

Während der UPDATE ENTITIES- und DELETE ENTITIES-Operationen sind die beiden Entitätsinstanzen in der globalen Sperrtabelle gesperrt. Dies ist während der CREATE ENTITIES-Operation nicht der Fall, da noch keine Schlüsselwerte vorhanden sind.

Beispiel - Mit Entwurf

Im folgenden Beispiel wird eine auf der CDS-Wurzel-View-Entität DEMO_RAP_UNMANAGED_DRAFT_ROOT basierte nicht verwaltete entwurfsfähige BDEF gezeigt.

Das Programm DEMO_RAP_UNMANAGED_DRAFT_LOCK greift über EML auf das Business-Objekt zu und führt die folgenden Schritte aus:

  • Hiermit werden zwei neue Entwurfsinstanzen der übergeordneten Entität angelegt.
  • Danach aktiviert er über die Entwurfsaktion Activate die Entwurfsentitäten.

Im folgenden Bild wird die globale Sperrtabelle (Transaktion SM12) während des Anlegens der neue Entwurfsinstanzen und vor Ausführung der COMMIT ENTITIES-Anweisung gezeigt. Die aktiven Instanzen sind gesperrt. Nach Abschluss der Entwurfsaktion Activate wird die Sperre entfernt.

IMAGE @@ABDOC_lock_table_2.jpg@@1238@@276@@

Variante 1

... lock master $[unmanaged$]


Wirkung

Hiermit wird eine Entität als Sperr-Master-Entität deklariert. Zur Zeit sind nur Wurzelknoten als Sperr-Master-Entitäten erlaubt.

In einem verwalteten RAP-BO ist die Implementierung standardmäßig durch das verwaltete BO-Framework gegeben. Falls der optionale Zusatz unmanaged verwendet wird, muss der Sperrmechanismus manuell in der Methode FOR LOCK des Behavior-Pools implementiert werden, genauso wie im nicht verwalteten Szenario. Er wird dann zur Laufzeit aufgerufen.

Variante 2

... lock dependent by _Assoc


Wirkung

Hiermit wird eine Entität als sperrabhängig definiert. Dadurch werden die Sperranforderungen an die Sperr-Master-Entität delegiert. Die Assoziation zwischen der sperrabhängigen Entität und der Sperr-Master-Entität muss über die Syntax association _AssocToLockMaster { } in der Entitätsverhaltensdefinition explizit definiert werden. Die Assoziation muss auch im zugrunde liegenden CDS-Datenmodell definiert sein.

Mit folgender kurzer Syntaxform wird eine Zusammenfassung der Sperrabhängigkeit, ETag-Abhängigkeit und Berechtigungsabhängigkeit angeboten:

($[lock$]$[, authorization$]$[, etag$]) dependent by _assoc

Weitere Details sind im Thema syntax_short_form enthalten.

Variante 3

... lock:none


Wirkung

Darf als Syntaxzusatz für eine Aktion verwendet werden, um den Sperrmechanismus für die Entitätsinstanz der ausgeführten Aktion zu verhindern. Siehe Abschnitt CDS BDL - action.






CPI1466 during Backup   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 16884 Date: 20240606 Time: 175551     sap01-206 ( 241 ms )