[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Apr 2020
    Beiträge
    3

    COMMIT-Stufe *RR eskalierte bis Sperre *EXCLRD.

    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

  2. #2
    Registriert seit
    Mar 2002
    Beiträge
    4.920
    ... 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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  3. #3
    Registriert seit
    Jan 2007
    Beiträge
    629
    ... und den on-exit, kannst Du auch gleich knicken, sofern Du eine "Cycle Main" Prozedur ausführst.
    kf

  4. #4
    Registriert seit
    Apr 2020
    Beiträge
    3
    Zitat Zitat von camouflage Beitrag anzeigen
    ... 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?

  5. #5
    Registriert seit
    Mar 2002
    Beiträge
    4.920
    ... 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)
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    18.613
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Mar 2002
    Beiträge
    4.920
    ... 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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

Ähnliche Themen

  1. sql commit und servicepgm
    Von mk im Forum NEWSboard Programmierung
    Antworten: 8
    Letzter Beitrag: 23-10-18, 14:35
  2. Commit im CL
    Von mk im Forum NEWSboard Programmierung
    Antworten: 10
    Letzter Beitrag: 09-03-17, 13:09
  3. Commit ?
    Von HEBORA im Forum NEWSboard Programmierung
    Antworten: 13
    Letzter Beitrag: 18-10-15, 20:00
  4. IFS und Commit
    Von mk im Forum NEWSboard Programmierung
    Antworten: 5
    Letzter Beitrag: 23-02-15, 15:57
  5. Commit Control
    Von lorenzen im Forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 06-02-01, 10:03

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •