COMMIT-Stufe *RR eskalierte bis Sperre *EXCLRD.

[x00]

Guten Morgen,
ich habe derzeit erste Berührungspunkte mit SQL-Transaktionen. Um ein grobes gefühl für das Thema zu bekommen habe ich folgendes kleines Programm geschrieben:

dcl-proc main;
dcl-pi *n;
end-pi;
//---
dcl-s x int(10) inz(0);

//Set the isolation level
exec sql set option commit = *RR;

//execute some sql
monitor;
exec sql delete from x.y where name = 'test commit';
x /= x;
exec sql commit;

//roll back if something bad happened
on-error;
exec sql rollback;
endMon;
//---
on-exit;
//---
end-proc main;

Im Joblog taucht nun diese meldung auf:

COMMIT-Stufe *RR eskalierte bis Sperre *EXCLRD.

Da das Programm genau das tut was es soll frage ich mich jetzt was diese meldung zu bedeuten hat. Ist sie wichtig? sollte man das Handlen?

Mit freundlichem Gruß
x00

[BenderD]

... Commit level repeatable read wird vom SQL Standard zwar als Regelfall gefordert, ist aber im DB2/400 nicht verwendbar, da bei dieser Sperrstufe ein write lock auf die gesamte Tabelle gesetzt wird (was die von Dir angeführte Meldung besagt).
Ist die Datei also zum write mit Rekord Löffel Ekzem geöffnet, geht das SQL nicht. War das SQL schneller, dann schmiert das RLA Programm bereits beim Start ab.

D*B

[camouflage]

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

[x00]

... und den on-exit, kannst Du auch gleich knicken, sofern Du eine "Cycle Main" Prozedur ausführst.
Den macht mein Snippet automatisch. :D

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