Read commit oder uncommit

[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.