Satzsperre nach Insert

[Allrounder]

Folgendes Problem:

Mithilfe eines SRVPGM werden Sätze in eine SQL-Tabelle geschrieben. Die Prozedur macht nichts anderes, als embedded einen Satz auszugeben, besteht also nur aus dem insert.

Die Tabelle wird sonst noch nirgends verwendet.

Das aufrufende RPG-Programm setzt sofort nach dem Prozeduraufruf einen commit ab (embedded).

Nach meinem Verständnis darf es nach dem commit keine Satzsperren mehr geben. Dennoch gibt es Satzsperren auf der Tabelle.

Wo ist der Fehler?
Ich hoffe, die Infos sind erst einmal ausreichend.

[BenderD]

wie siehts mit den ACTGRPs aus? per default verhält sich das so, als ob man pro ACTGRP eine eigene Connection hätte, der Commit hat also die Scope ACTGRP. Schau auch mal mit WRKCMTDFN (heißt das, meine ich) nach und mit DSPRCDLCK (heißt das, meine ich), ob deine Hypothesen alle richtig sind.
Ansonsten ist das ein Bug und kein Feature...
D*B

Folgendes Problem:

Mithilfe eines SRVPGM werden Sätze in eine SQL-Tabelle geschrieben. Die Prozedur macht nichts anderes, als embedded einen Satz auszugeben, besteht also nur aus dem insert.

Die Tabelle wird sonst noch nirgends verwendet.

Das aufrufende RPG-Programm setzt sofort nach dem Prozeduraufruf einen commit ab (embedded).

Nach meinem Verständnis darf es nach dem commit keine Satzsperren mehr geben. Dennoch gibt es Satzsperren auf der Tabelle.

Wo ist der Fehler?
Ich hoffe, die Infos sind erst einmal ausreichend.

[Fuerchau]

Fazit:
Wenn Service-Programme SQL-Update/Inserts machen, müssen diese mit ACTGRP(*CALLER) erstellt werden wenn die selben Commit-Grenzen gelten sollen.

Das Selbe macht übrigens SQL auch automatisch bei CREATE FUNCTION/PROCEDURE mit SQL-Body.

[Allrounder]

Danke Euch, das ist wohl das Problem.

Ich habe den commit in das steuernde Programm (ACTGRP: QILE) gelegt, das SRVPGM lief aber nach wie vor in einer benannten ACTGRP.

Wenn ich es richtig verstanden habe, hätte kein insert funktionieren dürfen, da ich in der benannten Aktivierungsgruppe keinen commit absetze. Das erklärt auch die fehlenden Datensätze.

Was mich aber wundert ist, dass ein Großteil der inserts funktioniert hat. Greift der commit des steuernden Programms doch?

[B.Hauser]

Hallo,

die Default-Einstellungen für den Commitment Scope im Start-Befehl StrCmtCtl ist *ACTGRP, d.h. eine Transaktion ist auf eine Aktivierungsgruppe beschränkt. Ein Commit und Rollback gilt immer nur für die Aktivierungruppe.

Wird Commitment Steuerung mit Commitment Scope *JOB gestartet, ist eine Transaktion Aktivierungsgruppen übergreifend. Solange keine 100% designete ILE-Anwendung vorliegt, sollte die Commitment Steuerung mit Commitment Scope *JOB gestartet werden.

Es kann also sein, dass in einem Start-Programm die Commitment-Steuerung immer mit Commitment Scope *JOB gestartet wird, wodurch es keine Probleme mit dem Commit gibt.

Ist keine Commitment Control gestartet und wird ein SQL-Statement unter Commit ausgeführt (unabhängig davon, ob dies interaktiv oder als embedded SQL geschieht), startet SQL Commitment Control selbständig, jedoch mit Default-Werten also Commitment Scope *ACTGRP.

Birgitta

[BenderD]

im beschriebenen Fall wirkt der Commit in der QILE auf alle unter Commit laufenden Dateifortschreibungen in der QILE, d.h. alle Sperren werden freigegeben und die Schreiboperationen festgeschrieben.
In der benamten ACTGRP werden alle unter Commit Steuerung laufenden Satzänderungen unter Vorbehalt durchgeführt und die Satzsperren bis zum Transaktionsende angehalten. Da aus dem Programm kein Commit oder Rollback ausgeführt wird, wird gesammelt bis zur zwanghaften Beendigung der Transaktiondurch Programmende (da kommt ein Rollback hinterher), oder durch RCLACTGRP, da kommt im default (Fassenacht in Rochester!!!) ein Commit hinterher.
BTW: von der Änderung des Commit Scope auf *JOB rate ich ab, das gibt nur Huddel!!! (ich weiß, da habe ich meine Meinung irgendwann mal geändert, aber man lernt halt dazu)

D*B

Danke Euch, das ist wohl das Problem.

Ich habe den commit in das steuernde Programm (ACTGRP: QILE) gelegt, das SRVPGM lief aber nach wie vor in einer benannten ACTGRP.

Wenn ich es richtig verstanden habe, hätte kein insert funktionieren dürfen, da ich in der benannten Aktivierungsgruppe keinen commit absetze. Das erklärt auch die fehlenden Datensätze.

Was mich aber wundert ist, dass ein Großteil der inserts funktioniert hat. Greift der commit des steuernden Programms doch?

[Allrounder]

Nochmals danke an alle.
Jetzt hat's "geklickt". Ich habe erst einmal die ACTGRP des SRVPGM auf *CALLER geändert. Damit sollte der commit des steuernden Programms greifen und die inserts laufen.

Die Änderung des CMTSCOPE auf *JOB werden wir im Team noch entscheiden müssen.

Viele Grüße
Allrounder

[BenderD]

lasst es bleiben, wenn man das einmal dahin geschoben hat, verliert man die Möglichkeit einen getrennten Commit Scope zu verwenden, was eine nicht hinnehmbare Einschränkung bedeutet. Es ist schon schlimm genug, dass man nicht mehrfach connecten darf (außer CLI etc...)

D*B

Nochmals danke an alle.
Jetzt hat's "geklickt". Ich habe erst einmal die ACTGRP des SRVPGM auf *CALLER geändert. Damit sollte der commit des steuernden Programms greifen und die inserts laufen.

Die Änderung des CMTSCOPE auf *JOB werden wir im Team noch entscheiden müssen.

Viele Grüße
Allrounder