Show TOC

BeispieldokumentationBeispiel: Endlostransaktion mit Verbuchung Dieses Dokument in der Navigationsstruktur finden

 

Motivation

Manche Business-Transaktionen sind als “Endlos-Transaktionen" implementiert, um sich aufwendige Initialisierung beim Beginn der Transaktion zu ersparen. Der Einsatz von optimistischen Sperren ermöglicht ein solches Vorgehen, da eine optimistische Sperre erst dann in eine Schreibsperre umgewandelt wird, wenn die Änderung tatsächlich durchgeführt werden soll. Der Verbuchungsteil der Sperre wird dann an die Verbuchung vererbt und nach Abschluss der Verbuchung freigegeben. Der Dialogteil der optimistischen Sperre bleibt bestehen.

Programmierung

Ziel ist es, eine optimistische Sperre anzufordern und dann den Dialogteil auf Dauer zu behalten.

Folgende Grafik zeigt den Verlauf der Operationen.

Die Abbildung wird im Begleittext erläutert.

Optimistische Sperre mit Verbuchung

  • Zuerst wird der Funktionsbaustein mit Sperrmodus O und _SCOPE=1 aufgerufen (1). Sie hat dann einen Eigentümer: den Dialogeigentümer E_1.

  • Im Verlauf der Transaktion wird zunächst dieselbe Sperre mit _SCOPE=2 angefordert, also um einen Verbuchungseigentümer (E_2) erweitert (2). Sie hat von nun an 2 Eigentümer

  • Wenn Daten geändert werden sollen, wird der Verbuchungsteil der Sperre in eine E-Sperre umgewandelt. Dies geschieht durch den Aufruf des Funktionsbausteins mit Sperrmodus 'R' und _SCOPE=2 (3). Diese Operation führt dazu, dass 2 Sperren existieren (vgl. untere Grafik): die O-Sperre mit dem Dialogeigentümer sowie eine E-Sperre mit dem Verbuchungseigentümer.

  • Im weiteren Verlauf wird die Verbuchung aufgerufen (4) und der COMMIT WORK abgesetzt (5).

  • Beim COMMIT WORK wird der Verbucher aufgerufen, der die E-Sperre und den Verbuchungseigentümer E_2 erbt. Gleichzeitig wird ein neuer Verbuchungseigentümer für die Dialogtransaktion angelegt (E_x).

  • Mit dem Ende der Verbuchung wird diese Sperre freigegeben. Nun existiert wieder nur eine Sperre mit Dialogeigentümer E_1 ohne Verbuchungseigentümer (vgl. untere Grafik).

Achtung Achtung

Erst wenn die E-Sperre in der Verbuchung freigegeben ist (6), kann in der Dialogtransaktion wieder eine O-Sperre für den VB-Owner E_x angelegt werden (Aktion (2)) Um diesen Zeitpunkt zu ermitteln, können Sie den _WAIT-Paremeter verwenden (vgl. Funktionsbausteine für Sperranforderungen). Anschließend kann die Promotion der O-Sperre in eine E-Sperre wieder erfolgen (3).

Ende der Warnung.

Die folgende Grafik zeigt, welche Sperren durch die Operationen in diesem Beispiel gesetzt werden, von welchem Typ die Sperren sind und welche Eigentümer sie haben (mit Kumulationszähler).

Der zeitliche Verlauf ist hier von oben nach unten dargestellt.

Die Abbildung wird im Begleittext erläutert.

Sperroperationen

(1) Eine optimistische Sperre mit _SCOPE=1, also nur Dialogeigentümer (E_1).

(2) Zu der bestehenden Sperre wird mit _SCOPE=2 ein Verbuchungseigentümer generiert (E_2).

(3) Der Verbuchunsgteil der Sperre wird in eine Schreibsperre (exklusiv) umgewandelt (Operation 'R', _SCOPE=2. Dies bewirkt, dass die O-Sperre ihren Verbuchungseigentümer verliert, und zusätzlich eine E-Sperre mit Verbuchungseigentümer E_2 (ohne Dialogeigentümer) besteht.

(4) Der Aufruf des Verbuchers ändert an dieser Situation nichts.

(5) Beim COMMIT WORK wird der Verbucher aufgerufen, der die E-Sperre und den Verbuchungseigentümer E_2 erbt.

(6) Nach Ablauf der Verbuchung und Freigabe der E-Sperre existiert wieder nur die O-Sperre mit dem Dialogeigentümer. Die Endlostransaktion kann also wieder Operation (2) ausführen.