Wie bekomme ich Record-Locking mit embedded SQL hin?

[BenderD]

Ich hätte gerne eine Sperre, die so arbeitet als hätte ich den Datensatz mit chain oder read gelesen.

Wenn ich einen Datensatz mittels SQL sperre, möchte ich natürlich, dass alle Programme, die den Datensatz noch mit "altem" read oder chain lesen, diese Sperrung beachten.

Zu unserem selbstgebauten Locking: Da wird einfach in einer Locktabelle für jeden zu sperrenden Datensatz ein Eintrag mit dem Dateinamen und der Record-ID des Datensatzes erzeugt. Jedes Programm, das den Datensatz sperren möchte, guckt vorher in dieser Tabelle nach, ob der Satz bereits von einem anderen Job blockiert wurde. Das Verfahren ist simpel und funktioniert natürlich nur, wenn sich alle an dieses Verfahren halten. Ein Programm, das dieses Verfahren nicht beachtet und sich einfach auf physische Datenbanklocks verlässt, erkennt so eine "logische" Sperrung natürlich nicht.

... genau das tut das skizzierte Verfahren.

... wobei eure logischen Sperren auch dann nicht funzen, wenn ein Programm mit Sperre stirbt und/oder die Sperre nicht wegmacht. (Das mit dem Absturz kann man natürlich heilen, mit Exit Handler)
Und wenn man das SQL in eine Lesefunktion zentralisiert, geht das logische auch mit SQL.

D*B

[dschroeder]

Bei SQL basierten Zugriffen verwenden wir in der Regel Zugriffsmodule, die lesen, schreiben, sperren, und löschen. Wenn ein Job, der eine Sperre eingetragen hat, nicht mehr aktiv ist, gilt die Sperre nicht mehr und wird automatisch aufgeräumt.

Aber zu den Datenbanksperren mit SQL: Ich komme also nicht drum herum, Programme, in denen ich SQL-Sperrungen haben möchte, speziell zu kompilieren. Ist etwas unschön, aber was will man machen ...

Vielen Dank für eure Antworten. Ich drohe schon mal damit, demnächst vielleicht mit weiteren Fragen dazu auf das Forum zuzukommen.

LG, Dieter

[BenderD]

Bei SQL basierten Zugriffen verwenden wir in der Regel Zugriffsmodule, die lesen, schreiben, sperren, und löschen. Wenn ein Job, der eine Sperre eingetragen hat, nicht mehr aktiv ist, gilt die Sperre nicht mehr und wird automatisch aufgeräumt.

Aber zu den Datenbanksperren mit SQL: Ich komme also nicht drum herum, Programme, in denen ich SQL-Sperrungen haben möchte, speziell zu kompilieren. Ist etwas unschön, aber was will man machen ...

Vielen Dank für eure Antworten. Ich drohe schon mal damit, demnächst vielleicht mit weiteren Fragen dazu auf das Forum zuzukommen.

LG, Dieter

... da gibt es nix mit anders koompilieren, das kann man in der Quelle mit sql options regeln. Ich rate allerdings dazu, das dann richtig zu machen.
1.) den Unfug mit dem geänderten command default beim CRTSQLRPGI abzustellen und den COMMIT(*NONE) in die SQL Options zu stellen.
2.) Dann werden die obigen Programme simple mit default gewandelt.
3.) Das Commit(*NONE) richtigstellen und mit commit arbeiten.

D*B

[dschroeder]

... da gibt es nix mit anders koompilieren, das kann man in der Quelle mit sql options regeln. Ich rate allerdings dazu, das dann richtig zu machen.
1.) den Unfug mit dem geänderten command default beim CRTSQLRPGI abzustellen und den COMMIT(*NONE) in die SQL Options zu stellen.
2.) Dann werden die obigen Programme simple mit default gewandelt.
3.) Das Commit(*NONE) richtigstellen und mit commit arbeiten.

D*B

Das klingt gut. Vielen Dank!
Ich werde das mal ausprobieren.

Schönen Abend an alle.

[Fuerchau]

Du kannst ja nach dem Fetch des For-Update-Cursors einen "update table where current of cursor" durchführen. Der sperrt so lange, wie kein Commit gemacht wird, wenn *CHG verwendet wird.
Dafür ist es natüürlich wichtig, dass dein Sperrprogramm in einer benannten ACTGRP läuft sonst hebt irgendein Commit im Job deine Sperre auf.

[BenderD]

Du kannst ja nach dem Fetch des For-Update-Cursors einen "update table where current of cursor" durchführen. Der sperrt so lange, wie kein Commit gemacht wird, wenn *CHG verwendet wird.
Dafür ist es natüürlich wichtig, dass dein Sperrprogramm in einer benannten ACTGRP läuft sonst hebt irgendein Commit im Job deine Sperre auf.

... unter commit kriegst du eine ausreichende Sperre erst mit dem update. Bei change sperrt der read überhaupt nicht. Ohne commit sperrt der for update cursor schon beim read, welche Sperre der genau setzt, habe ich nicht parat - ich arbeite grundsätzlich immer mit commit, weil das Stand der Technik ist und damit erforderlich für Revisions sichere Programme.

D*B