Motivation

In Business- Anwendungen werden zunehmend Dialoge angeboten, bei denen Daten im Änderungsmodus angezeigt werden, wobei die Wahrscheinlichkeit nicht hoch ist, dass die angezeigten Daten auch geändert werden. Ein Locking-Verfahren muss garantieren, dass bei konkurrierendem Zugriff auf gleiche Daten eine konsistente Änderung sichergestellt ist.

Das für Locking in ABAP-Programmen verwendete SAP Sperrkonzept („Enqueue“) bot früher nur ein pessimistisches Locking an, was dann gut geeignet ist, wenn die Wahrscheinlichkeit hoch ist, dass es zu Datenänderungen kommt, aber im oben genannten Fall zu unerwünschten Einschränkungen in der Parallelität führt. Es äußert sich dadurch, dass zu einem Zeitpunkt nur in einem von mehreren parallelen Dialogen die Daten als änderbar dargestellt werden können.

Aus diesem Grund entstand die Forderung nach einem optimistischen Locking-Verfahren für ABAP-Programme. Damit kann Änderbarkeit in allen parallelen Dialogen angeboten werden, allerdings muss die Business-Anwendung darauf vorbereitet sein, dass die ursprünglich angezeigten Daten sich bereits geändert haben, bevor die eigene Änderungen wirksam wird. Dieser Fall muss im Locking-Verfahren detektierbar sein, um der Business-Anwendung die Möglichkeit zu geben, eine Konfliktlösungsstrategie zu verfolgen.

Sperrmodus „O“

Neben den Sperrmodi S, E und X gibt es für optimistische Sperren den Sperrmodus O.

Eine optimistische Sperre (Modus O) wird gesetzt, wenn der Benutzer die Daten im Änderungsmodus anzeigt. Optimistische Sperren auf dasselbe Objekt kollidieren nicht. Will der Benutzer die (geänderten) Daten sichern, muss die optimistische Sperre in eine Schreibsperre (Modus E) umgewandelt werden. Die Umwandlung wird mit dem Sperrmodus R implementiert. Dies schlägt fehl, wenn vorher jemand eine nicht optimistische Sperre auf das Objekt gesetzt hat oder bereits eine andere O-Sperre promoviert wurde. Gelingt die Promotion, werden die anderen optimistische Sperren auf das Objekt gelöscht und die Sperre verhält sich wie eine E-Sperre.