COMMIT-Stufe *RR eskalierte bis Sperre *EXCLRD.

[x00]

... und den on-exit, kannst Du auch gleich knicken, sofern Du eine "Cycle Main" Prozedur ausführst.

Den macht mein Snippet automatisch.

Ok, dann wäre aber ja meinem verständnis nach (dessen was ich grad auf wikipedia gelesen habe lol), die option *CS besser da ich damit zumindest den dirty read (mein Hauptproblem) ausschließe. Oder?

[BenderD]

... der CS funktioniert nur, wenn Du über cursor liest, beim select into geht der in den Wind. Hauptproblem im DB2/400 sind eher die Deadlocks (das mit dem dirty read funktioniert eh nicht immer, wie man das will), weil die Sperrstufe zwischen read (mit Sperre) und write erhöht wird.
Bei updates ohne Konflikt Wahrscheinlichkeit ist das, was DB2/400 *ALL oder *RS nennt besser.
Bei Konflikt Wahrscheinlichkeit ist es am besten mit einem dummy update einzusteigen, dann lesen, dann fortschreiben.

D*B

PS: Die Krux fängt schon mit der idiotischen Benennung der Sperrstufen an:
NO COMMIT (NC, NONE)
READ UNCOMMITTED (UR, CHG)
READ COMMITTED (CS)
REPEATABLE READ (RS, ALL)
SERIALIZABLE (RR)

[Fuerchau]

Jein:
*CS sperrt alle gelesenen Daten. Sollte ein anderer Prozess auf die Daten zugreifen wollen, wird dieser gesperrt.
Andererseits wird dein Prozess geparkt, bis die nicht bestätigten Daten (committed) bestätigt oder zurückgesetzt wurden.
In beiden Fällen kann es daher auch zu Abbrüchen (Recordlock-Timeout) kommen.

[BenderD]

... das Problem ist, dass gelesene Sätze nur mit share no update gesperrt werden, d.h. dass 2 Prozesse denselben Satz zum update lesen können und keiner ihn fortschreiben darf. Klassischer Fall von Deadlock auf demselben Satz und einem idiotisch implementierten Datenbanksystem.

D*B