View Full Version : Satzsperren verteiulte Programme
Hallo Zusammen,
ich benötige mal einen basic Input.
Ein Programm A ruft ein Programm B auf. Beide Programme laufen unter Commit und nutzen die selbe LF und befinden sich auch in der selben Aktivationgroup.
Programm B bricht ab beim Chain auf die LF mit Satzsperren. Programm A hat auch einen Chain gemacht, daher ist der Satz gesperrt, aber ich dachte, dass innerhalb der selben Activation Gruppe dies kein Problem bereitet, aber tut es wohl doch. Ich habe geschaut, Programm A hat keine offene Commits.
Noch zur Info: Das Programm B wird auch noch von anderen Programmen aufgerufen.
Ich habe dann einen close im PGM A gemacht, das hat dann zwar funktioniert, aber die Datei wäre dann für einen Moment frei, was nicht OK ist.
Danke schon mal.
Gruß Klaus
Satzsperre hat nicht immer mit commit zu tun.
Ein (für Updater) gelesener Satz ist gesperrt bis das Update kommt, ein anderer Satz der gleichen Datei gelesen wird oder ein unlock gemacht wird.
Wenn mit Commit gearbeitet wird, können mehrere Update als 'Gruppe' definiert werden und, im Fehlerfall, gemeinsam zurück gedreht werden. (Datei intern oder auch übergreifend)
Unter commit ist ein Satz erst mit dem Commit/Rollback frei, ohne Commit beim update/unlock
Ja, genau, bisher hat das auch immer sehr gut funktioniert. Nur jetzt kommt das PGM B auf Satzsperren, die sich mir nicht erschließen.
Die Commit Logik ist wie folgt:
CL PGM: STRCMTCTL LCKLVL(*CHG) CMTSCOPE(*JOB)
CL ruft PGM A auf unter commit
PGM A ruft B auf unter Commit
PGM A macht dann den Commit oder Rollback im Fehlerfall
Du musst unterscheiden zwischen SQL und RLA (klassisch).
Commit(*CHG) besagt ja nur, dass geänderte Daten bis zum Commit gesperrt bleiben.
Beim Lesen mit SQL Select entsteht erstmal keine Sperre.
Machst du aber per Chain/READ/READE einen Zugriff auf eine PF/LF die für Update geöffnet ist, wird weiterhin eine Sperre auf diesem Satz gesetzt.
Dies entspricht i.Ü. auch dem "Select .... for update".
Vorsicht ist bei einem Commit(*CS/*ALL). In diesem Fall werden alle gelesenen Sätze mit Select ebenso gesperrt.
Für einen erfolgreichen Commit/Rollback müssen alle betroffenen Tabellen in einem Journal aufgezeichnet sein. Bei F-Bestimmungen müssen die Dateien ebenso mit "commit" gekennzeichnet werden da sonst für diese Zugriffe intern automatisch "with nc" angewendet wird.
Dies gilt i.Ü. auch für SQL: "Update ... with nc" untergräbt eine Transaktionskontrolle.
Nachtrag:
Wenn du dieselbe Tabelle per F-Bestimmung sperrst wird ein anderer SQL auch im selben Job gehindert einen Update durchzuführen da SQL den Open der F-Bestimmung nicht verwendet.
https://www.ibm.com/docs/en/i/7.1?topic=control-commit-lock-level
Danke, aber die Definitionen sind mir bewusst, ich nutze dieses Logik schon seit Jahren, nur wieso gibt es eine Satzsperre im gleichen Aufrufstapel und in der gleichen Commit Umgebung, sprich Programm B bricht ab, weil Programm A den Satz gesperrt hat. Ich meine, dass dies schon immer funktioniert hat, kann mich aber täuschen.
letzteres
bla bla bla um auf 20 Zeichen zu kommen
Das funktioniert nur unter 1 Bedingung:
Die PF/LF muss mit SHARE(*YES) definiert sein, dann wird der Open übergeordneter Programme übernommen.
Aber Vorsicht:
Wenn Programm A mit I öffnet, wird Programm B auch mit I öffnen, selbst wenn U angegeben ist.
SQL interessiert Share jedoch nicht. Je nach Optimierung und Vergleichbarkeit einer Abfrage wird derselbe sog. ODP wieder verwendet.
Allerdings kann es da durch Unterschiede auch hier zu mehrfachem Open kommen.
Moin,
das ist so. Immer share(*YES). Beide Programme haben die Datei mit update eröffnet. Es ist ja auch die selbe LF und der selbe Satz der gesperrt ist.
Zum Hintergrund:
PGM A soll den Satz sperren, damit zwischen PGM Aufruf A-> B kein anderes PGM den Satz sperren kann.
PGM A macht den CHAIN und PGM B macht den CHAIN.
Ja, aber dies gilt nicht, wenn du in PGM B mit SQL einen Update machen willst. Da ziehen diese Methoden nicht mehr.
Ist ja kein SQL update, ganz normaler RPG update.