Problem mit Commitsteuerung

[Fuerchau]

Betrachte dann bitte die Aktivierungsgruppen bzw. die Commit-Gruppen des Jobs.
Hinzu kommt natürlich, dass Satzsperren bis zum commit bestehen bleiben.
Da in SQL immer dieselbe Datei nur 1x geöffnet wird (ODP => Open Data Path), ist das kein Problem.
Bei Datei-Open ist es aber schon immer so, dass hier jeder Open eigene Sperren setzt.

Prüfe also bitte noch mal die Commit-Definitionen des Jobs zu jedem Zeitpunkt.

[harkne]

Danke,

aber an einem Punkt muss ich dann doch nochmal nachfragen

Da in SQL immer dieselbe Datei nur 1x geöffnet wird (ODP => Open Data Path), ist das kein Problem.

heißt das, dass wenn ich ein Programm am Laufen habe was unter Commit ein SQL-UPDATE gemacht hat aber noch keinen COMMIT ausgeführt hat, dass in dieser Zeit kein anderes Programm was die selbe Datei unter Commit hat auf die Datei via SQL zugreifen kann oder kein anderes Programm was die selbe Datei unter Commit hat die Datei via SQL updaten kann?

[Fuerchau]

Das ist korrekt und Sinn der Transaktion.
Eine Transaktion soll ja sicherstellen, dass diese Daten in sich konsistent bleiben.
Daher gibt es eine ungeschriebene Regel:
Keine Transaktion darf über eine Userinteraktion hinaus gehen um Ressourcen zügig wieder frei zu geben.
Warum? Du könntest einen Rollback machen und die Änderungen anderer wären dann auch weg.

Transaktionen sind die kleinsten gemeinsamen Aktionen, die eine Aktivität zu einer unteilbaren Einheit verbindet.
Z.B.: Auftragsposition erstellen/anpassen/löschen + Bestandsreservierung.
Eine komplette Auftragserfassung sind daher mehrere Transaktionen.
Z.B.: Rechnung schreiben: Alle Aktivitäten der einzelnen Rechnung sind eine Transaktion, da die Rechnung unteilbar ist.
Usw., usf., etc, bla, bla, bla!

Daher kann ich mir nun nicht vorstellen, dass eine Transaktion über mehrere Programmschritte geht (da sind Services nicht mit gemeint, da diese ja innerhalb der Transaktion benötigt werden).

[harkne]

@Fuerchau. Ich brauche jetzt zum Verständnis nochmal ein abnicken.

Gehen wir von Aufträgen und Auftragspositionen aus

In den nachfolgenden Fällen wurde vorher ein STRCMTCTL gemacht


Beim normalen READ/CHAIN und UPDATE

Wenn ich Auftrag 1 mit Position 1 und 2 geschrieben habe, habe ich auf diese Sätze eine Sperre solange bis ich den COMMIT oder ROLBK ausführe.

Ein ganz anderes Programm (oder aber auch das selbe Programm von einer anderen Sitzung aus aufgerufen) was auch unter commit läuft kann dann problemos auf Auftrag 2 zugreifen und dort was ändern. Hält natürlich dort die Sperren auch bis ein COMMIT oder ROLBK erfolgt.

Wenn ich das jetzt richtig verstanden habe verhält es sich aber bei SQL anders
Wenn also Programm 1 jetzt mit SQL SELECT, UPDATE arbeiten würde und ich hätte einen UPDATE auf einen oder mehrere Sätze des Auftrags 1 gemacht ohne einen COMMIT auszuführen. Dann könnte ein anderes Programm (oder eben wieder dieses von einer anderen Sitzung aus) gar nicht auf die Datei via SQL zugreifen und/oder keine UPDATES machen. Egal ob dieses dann den UPDATE auf Auftrag 2 machen wollte?

Habe ich das richtig verstanden?

Das heißt im Falle von SQL habe ich den Vorteil dass ich keine konkurierenden Locks erzeugen kann, dafür aber wahrscheinlich etwas länger warten muss bis die Datei wieder frei ist?

Viele Grüße Harald

[Fuerchau]

Nein hast du leider nicht verstanden.
Du must unterscheiden zwischen Programmen in derselben Sitzung und verschiedenen Sitzungen.
Jede Sitzung hat eine eigene SQL-Umgebung und weiß nichts von einer anderen.
In einer Sitzung hat jede ACTGRP ihre eigene SQL-Umgebung und weiß nichts von der Anderen.

Jede SQL-Umgebung hält Update/Insert/Delete-Sperren auf Satzeben je Datensatz.
Somit kann jede SQL-Umgebung auf andere Datensätze derselben Tabelle eintsprechende Aktionen durchführen (der SQL-Server macht das auch gerne anders, nicht aber die DB2).
Sämtliche Ressourcen werden mit commit bestätigt und freigegeben, mit rollback zurückgedreht aund ebenso freigegeben.

Innerhalb einer SQL-Umgebung wird jede Tabelle genau nur einmal geöffnet, egal wievele SQL's auf die Tabelle in derselben ACTGRP gemacht werden.

Native Dateien (PF/LF) werden mit Open von jedem Programm geöffnet. Bei Calls und Open derselben Datei bekommt man einen 2. Open.
Ausnahme mit SHARE(*YES) bleibt der 1. Open und wird nur hochgezählt. Dies ist aber manchmal schwierig, da ein 1. Open Input mit einem 2. Open Input/Output dann in die Hose geht.
Satzsperren sind dann auf jeder geöffneten Datei separat möglich.

[harkne]

OK. Ich war ein klein wenig erschrocken wegen dem wie ich es verstanden hatte.

Vielen Dank.