View Full Version : JVAGATE offene Commits im Joblog
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.
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.
@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