Read commit oder uncommit

[Fuerchau]

Das sich CPYF durchaus mit Commit und Journal verträgt habe ich nicht bestritten.
Allerdings gibt es halt die Fälle, in denen man mal STRCMTCTL im Job gestartet hat und nicht wusste dass da irgendwo CPYF's laufen die mit Transaktionen nicht rechnen.
Deswegen könnte ein CPYF scheitern, wenn dieser unerwartet in eine Transaktion rennt, ins besonders dann, wenn dann das Locklimit des Jobs erreicht wird.

[B.Hauser]

Das sich CPYF durchaus mit Commit und Journal verträgt habe ich nicht bestritten.

Copy-Files und CLRPFM laufen NICHT unter Commitment Control, auch wenn diese gestartet ist.

Ein ROLLBACK (unabhängig davon ob mit Commitment Scope *JOB oder *ACTGRPDFN gearbeitet wird) wird die kopierten und gelöschten Datensätze nicht zurücknehmen bzw. wiederherstellen.
Im überigen ist das Kopieren von Daten in (temporäre) Dateien auch kein gutes Design.

Birgitta

[Fuerchau]

Ob ich nun früher ein CPYF ggf. mit OPNQRYF gemacht habe oder nun einen "CREATE TABLE as Select ... with data", wo ist das der Unterschied?
Außerdem gibt es durchaus Gründe, temporär Daten zu extrahieren um damit performanter umzugehen.
Gott sei dank gibt es ja die QTEMP, so dass ich nicht mit komplexen Konstrukten in Tabellen mit "temporären Schlüsseln" umgehen muss.
Ins besonders da die QTEMP automatisch aufgeräumt wird. Von schlechtem Design würde ich da nicht sprechen, eher von "erkannten Möglichkeiten".

Und was sind denn dann "Global tamporary tables"? Die liegen doch ebenso letztlich in der QTEMP.

[BenderD]

@Banausen und ACTGRP:

Gutes Design orientiert sich nicht an den Altlasten, sondern an künftigen Anforderungen. Commit funktioniert dann "sauber", wenn Schreiboperationen, die zu einer Transaktion gehören, als gesamtes geklammert werden und komplett ausgeführt oder verworfen werden. Das erfordert zuweilen, dass mehrere Transaktionen einander überlappen können und voneinander unabhängig sind.

Dazu hat man bei Commit Steuerung Commit Master, die für die Steuerung verantwortlich sind und Slaves. Commit und Rollback sagt immer nur der Master, die slaves laufen in ACTGRP *CALLER. Will man mehrere ACTGRPs zu einer (übergeordneten) Transaktion koppeln, macht man das wie bei mehreren Connections zu verschiedenen Datenbanken, dann wird überall commited oder zurück gesetzt.

Startet man commit mit ACTGRP *JOB, macht man die Commit Steuerung von eingebundenen (Fremd) Anwendungen kaputt, das ist ein ernsthafter Kunstfehler!

D*B

[Fuerchau]

CLRPFM kann man tatsächlich keinen Rollback machen da die einzelnen Zeilen nicht journalisiert werden, bei CPYF werden wieder einzelne Zeilen "inserted" so dass ein Rollback möglich sein sollte.
Aber das kann man ja ausprobieren;-).

Es gibt übrigens eine SQL-Optimierung bzgl. "delete from mytable":
Wenn keine Journalisierung und kein Trigger, dann wird ein CLRPFM versucht.
Da dieser exclusive Lock benötigt, wird im Fehlerfall wieder ein Einzelsatz-Delete durchgeführt.
Dies kann daher schon mal zu unterschiedlichen Performanceeffekten führen.