JVAGATE offene Commits im Joblog

[itec01]

Guten Morgen,
noch eine Frage:
Wegen der dynamischen LIB habe ich eine Variable tablename definiert und wollte diese in exec sql einbinde, leider motzt der Precompiler.

c/exec sql
c+ update :tablename set changerid = :W_userid
c+ where id = :W_Id
c/end-exec

:tablename wird durch den precompiler angemotzt.
SQL0104 30 171 Position 16 Token : was not valid. Valid tokens:

Eventuell muss ich den kompletten SQl String in eine Variable packen?
c/exec sql
c+ execute immediate :W_Sql
c/end-exec


Danke.

[BenderD]

... das ist eigentlich SQL Basiswissen, Dateinamen, Feldnamen, etc müssen bei static SQL zur Umwandlungszeit feststehen. Ansonsten dynymic mit prepare und execute using.

prepString = 'update ' + tablename + ' set afield = ? where somefield = ?';
exec sql prepare myStatement from repString;
exec sql execute myStatement using :afield, :somefield;

D*B

PS: Margery (AKA die allwissende Müllhalde, alias google) hat zahlreiche Beispiele für prepare execute und warum man Parameter Markers verwenden soll.

[itec01]

@Dieter, vielen Dank.
Eine Frage noch zu JVAGATE.
Wenn wir bei der fernen DB Sätze sperren und der User zum Beispiel blöderweise das X drückt, dann kommt das Programm nicht in die PSSR und die Sätze bleiben gesperrt und zwar solange bis JVAGATE beendet ist (läuft bei uns als ASYNC JOB).
Gibt es hier eine bessere Lösung, sprich eventuell über einen Timeout konfigurierbar in der JVAGATE Config Datei?
Danke.
Klaus

[Fuerchau]

Dann ist das Design fehlerhaft.
Innerhalb einer Transaktion darf es nicht zu einer Userinteraktion kommen.
Also alles mit Monitor umschließen und mit Commit bei OK sowie Rollback bei Fehler beenden.
Damit kann keine Sperre offenbleiben, denn beim Lesen wird nichts gesperrt.

[itec01]

Wir sperren auch die zu lesenden Sätze, weil wir nicht ausschließen können, dass jemand vom fremden System etwas an den Sätzen macht (select ... for update). Wir haben das getestet und die Sätze blieben offen, wenn der JOB sich ohne PSSR verabschiedete. Ja, bei Update, Insert kann das nicht passieren. Da muss ein Monitor drum herum, bzw. in der PSSR der ROLLBACK rein.
Beim Beenden von JVAGATE sind die Sätze wieder frei. Daher gibt es vlt. auch eine Art Timeout. Wird der Timeout erreicht, dann werden die Sätze freigegeben.

[Fuerchau]

Nein da gibts nichts. Wenn ihr einen Async-Job habt, sollte bei Sperren eine regelmäßige Prüfung des Asyncjobs stattfinden, ob der Job, der die Sperre ja setzt, noch aktiv ist.
Dafür gibts die Table-Function ACTIVE_JOB_INFO um das schnell auszuwerten.
Dies kann der Asyncjob ja alle x Sekunden prüfen, da ein QRCVDTAQ auch einen Timeout erlaubt.

Allerdings kann eine Satzsperre bei Fremdsystemen über einen längeren Zeitraum zu schweren Fehlern der daran hängenden anderen Apps führen. Bei der IBM i gibts einen Lock-Timeout, beim SQL-Server z.B. einen infinitive wait.
Konzeptionell, ich muss das sagen, ist das ein Schwachpunkt.

Generell ist zu empfehlen:
- Daten lesen ohne Sperre für die Anzeige
- Useraktion abwarten
- Daten lesen mit Sperre und die Voraussetzungen noch mal prüfen
- falls nicht OK dann Rollback mit Hinweis an den User
- falls OK dann verarbeiten und Commit.
Damit können andere machen was sie wollen, da auf Veränderungen zum Transaktionszeitpunkt reagiert werden kann.

[BenderD]

@Dieter, vielen Dank.
Eine Frage noch zu JVAGATE.
Wenn wir bei der fernen DB Sätze sperren und der User zum Beispiel blöderweise das X drückt, dann kommt das Programm nicht in die PSSR und die Sätze bleiben gesperrt und zwar solange bis JVAGATE beendet ist (läuft bei uns als ASYNC JOB).
Gibt es hier eine bessere Lösung, sprich eventuell über einen Timeout konfigurierbar in der JVAGATE Config Datei?
Danke.
Klaus

... ArdGate macht genau das, was ihm gesagt wird , das Verhalten bei Satzsperren hängt von der spezifischen Datenbank ab und kann über Treibereinstellungen modifiziert werden. Beim Jobende schickt die Datenbank der AS400 ein Rollback hinterher und sowohl lokale als auch remote Satzsperren werden freigegeben. Was hängen bleibt, ist die Connection, auch hier kann es Einstellungen beim treiber geben.

Bei sauberer Vorgehensweise erledigt man das im Programm durch Registrierung eines Exit Handlers, der beim Ende der Aktivierungsgruppe vom System aufgerufen wird (Beispiele in allen JVAGATE RPG Programmen) und den disconnect durchführt.

D*B