Journaling Commit/rollback

[AndreasH]

Hallo Forum,
wir möchten unsere Nummernkreisdatei auf Journaling umstellen. Da wir in der Richtung absolut unvorbelastet durch Wissen jeder Art sind lieber vorab ein paar Fragen nach Stolpersteinen:
Zenario 1: user01 greift auf Satz 1 zu

Key = "AUFTRAG"
AktNum = 4711

Begsr GetNum ;
CHAIN NumKey NumKreis ;
if %found(NumKreis01) ;
RtnNum = ActNum ;
ActNum = Actnum + 1 ;
update NumKreis ;
EndIf ;
EndSr ;

User02 greift mit einem anderen Job auf den satz zu und erhält 4712.
Wenn nun bei User01 alles gut geht wird die Nummer im Beispiel auf 4712 gesetzt und mit commit fortgeschrieben.
User02 hat den satz auf 4713 geändert. Alles gut soweit.

Bei fehler, wie ist die Reihenfolge?
Kommt es bei User01 zu einem Rollback statt commit NACHDEM User02 sein commit abgesetzt hat:

1. Geht das überhaupt? Oder bleibt der Satz durch User01 bis zum commit gesperrt?
2. Steht in der Datei nach User01 rollback 4713 oder 4711?
3. Wie verhindere ich "fehlende Nummern (zB Rechnungsnummern "sollten" keine Lücken aufweisen mit dieser Technik?
Danke für alle Antworten

[Fuerchau]

Unter Commit bleiben Sätze, die per Update/Write verarbeitet werden bis zum Commit/Rollback gesperrt !!!

Ein Lesen ohne Lock ist generell möglich, es sei denn beim STRCMTCTL wurde LCKLVL(*ALL) angegeben. Dann bleiben auch Sätze die mit Sperre gelesen wurden bis zum Commit gesperrt.

Aber Achtung:

Innerhalb eines Zyklus (Commit -> Commit/Rollback) können durchaus mehrere Sätze einer Datei gesperrt werden !!
Dies erfordert ggf. ein Umdenken der Abläufe, insbesonders wenn über diverse LF's auf die Daten zugegriffen wird.

Programme die OHNE STRCMTCTL die Daten verarbeiten (und das ist dann nicht verboten), arbeiten wie bisher, d.h., die Daten werden zwar journalisiert aber es kann nur 1 Sperre pro Datei gehalten werden.

Ausserdem sollte man sich an den "Transaktionsgedanken" gewöhnen. Dies ist besonders bei Dialogprogrammen wichtig, da dort eine "Transaktion" (= von Commit bis zum nächsten Commit) nicht von einer Benutzeraktion unterbrochen werden sollte (warten auf Datenfreigabe/F-taste o.ä.) denn genau dann könnte der User in die Pause gehen.

Auch sollte man wissen, das das System automatisch einen Rollback macht, wenn der Job / Activationgroup beendet wird und nicht wenn das Programm mit *INLR=*ON abgeschlossen wird !!!

Nun gezielt zu deiner Frage:
Antwort 1 erhält 100 Punkte !!

[B.Hauser]

Noch eine Anmerkung:

Wird ein Satz unter Commit im Update-Modus eingelesen, bleibt er bis zum nächsten Commit oder Rollback gesperrt.
Kein anderer Job kann diesen Satz im Update-Modus einlesen.

Das heisst, dass auch Aktionen wie Read(N) oder UNLOCK den Satz nicht freigeben!

Weiterhin muss man beim STRCMTCTL aufpassen, der Unterlassungs-Wert für CMTSCOPE ist *ACTGRP.
Wird in einer ILE-Umgebung mit unterschiedlichen Aktivierungs-Gruppen gearbeitet, muss dies unbedingt berücksichtigt werden.

Überigens erfolgt beim Beenden eines Jobs oder einer Aktivierungs-Gruppe nur dann ein Rollback wenn der Job oder die Aktivierungs-Gruppe abnormal beendet wurden.
Bei einer normalen Beendigung z.B. über Signoff werden die Änderungen festgeschrieben.

Andreas:
wenn Du in Deinem Beispiel mit Commitment-Steuerung arbeitest, kommt ein weiterer Benutzer nicht an den Satz solange er gesperrt ist.
Wenn also Benutzer1 einen Rollback macht, bekommt Benutzer 2 wieder die gleiche aktuelle Nr.

Ich würde allerdings die Nummerkreis-Datei nicht unter Commit stellen, um Wartezeiten, die durch den LOCK verursacht werden zu vermeiden.
(Ich nehme an, dass du den Satz solange sperren möchtest, bis die ganze Aktion z.B. alle Buchungen durchgeführt sind)
Sicher, wenn es im Nummerkreis keine Lücken geben darf muss man diese Lösung vielleicht in Betracht ziehen.

Birgitta

[AndreasH]

Vielen dank Fuerchau und Birgitta.
Das gibt uns wieder eine ganze Menge Stoff zum Überdenken, bevor wir mit fliegenden Fahnen ans Journalisieren gehen...