PDA

View Full Version : Commit und Rollback bzw. nicht Rollback



wti
12-05-17, 10:56
Moin zusammen,

noch eine Anfrage zu dem o.a. Thema im Rahmen unserer Anwendungsmodernisierung.

Derzeit erstellt mein Kunde eine Anwendung mit .Net und der Verbindung über DB2connect zum System i.
Über SQL-Trigger werden die "neuen" Daten in die "Alte Welt" geschrieben. Die ganze .Net Anwendung läuft unter einer Transaktionssteuerung, die im Fehler-Fall alle Datenbank-Änderungen zurücksetzt(Rollback).
Allerdings werden über SQL-Trigger/Stored Procedures auch Log- und Error-Tables geschrieben, die natürlich nicht vom Rollback betroffen sein sollen.

Wie lässt sich das bewerkstelligen. Derzeit sind nach dem Rollback auch die Einträge in den Log- und Error-Tables verschwunden, was die Analyse wesentlich erschwert.
Die Ausgabe dieser Daten erfolgt entweder direkt mit einem SQL-Trigger oder über eine Stored Procedure, die aus einem SQL-Trigger aufgerufen wird.

Vielen Dank für eure Hilfe.

BenderD
12-05-17, 11:14
... commit scope ist die connection. Wird vom :net geschrieben, braucht man für die log/error Ausgaben eine eigene Connection. Wird das lokal auf der AS gemacht, ist commit scope die ACTGRP. Etwas einfacher, aber weniger Transaktions scharf, ist die Error Ausgabe nach dem rollback in einer weiteren Transaktion.

D*B

Fuerchau
12-05-17, 12:30
Oder andersrum gesagt:
Wenn das Programm für das Log in einer eigenen ACTGRP liegt, unterliegt er nicht dem Commit/Rollback.
D.h., der Trigger muss ein Log-Handler/Service-Prozedur in einer eigenen ACTGRP aufrufen.

BenderD
12-05-17, 12:39
... man könnte allerdings auch die DB2 Erweiterung von SQL benutzen und eine isolation clause (with NC) bei den Schreiboperationen der LOG und Error Daten ergänzen. Einzelheiten und Beispiele: frag Tante Google oder RTFM

D*B

B.Hauser
14-05-17, 13:13
Sofern die Logs mit RPG geschrieben werden, wird in den F-Bestimmungen kein Commit angegeben.

Sofern die Logs mit SQL geschrieben werden, wird am Ende des Insert/Update-Statements WITH NC (= with NO Commit) angegeben.
Dann spielt es auch keine Rolle, ob der Insert/Update unter Commitment Control ausgeführt wird oder nicht und ob der commitment scope beim STRCMTCTL (Start Commitment Control) auf *ACTGRP oder *JOB steht.

Birgitta