View Full Version : Wie bekomme ich Record-Locking mit embedded SQL hin?
dschroeder
01-12-23, 14:15
... was für eine Sperre hättest Du denn gerne?
Einfach und nahe dran am Rekord Löffel ist:
- Programm mit commit wandeln
- dummy update auf Satz
- Satz lesen
... whatever you want
- freigeben mit commit
Gegenfrage: was verstehst Du unter "selbstgebautes Locking Verfahren?
D*B
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.
Wir haben alle Tabellen journalisiert. Was heißt denn "Du solltest jedoch Commit=*CHG verwenden" ? Kann ich das im Code angeben oder muss ich dazu Programme mit anderen Optionen kompilieren?
... schau dir mal den default von CRTSQLRPGI an (bevor irgendwelche Dilettanten den verändert haben), das ist eine Compile Option.
Vorsicht: *CHG setzt keine Sperre beim lesen, sondern erst beim schreiben.
doppelt Vorsicht: SQL setzt bei höherem Sperrlevel beim lesen eine shrnupd Sperre, die dann beim schreiben eskaliert wird (was zu Deadlocks führen kann), bei dem der spätere (!!!) gewinnt.
dreifach Vorsicht: Sperrelvel serializable setzt eine Sperre auf Dateiebene, was mit Rekord Löffel zu Abbrüchen führt.
D*B
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
01-12-23, 15:10
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
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
01-12-23, 16:12
... 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.
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.
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
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.
... noch eine Bemerkung zu eurem Sperrverfahren:
Ich würde hier Satzsperren und Prozesssynchronisation gedanklich voneinander trennen. Satzsperren sind kurz andauernd (Milllisekunden) und dienen der Transaktionskontrolle, das macht die Datenbank automatisch und hier dürfen keine lang andauernden (mehar als eine Bildschirmtransaktion) Sperren auftreten.
Prozesssynchronisation benötigt lang andauernde Sperren, bis ein anderer Prozess fertig ist. Hierunter fallen z.B.: Reisebuchungen, Verwaltung von Versicherungsverträgen können dazu gehören, auch Bestellungen mit Reservierungen können dazu gehören; in dieselbe Kategorie fallen auch etliche Batchprogramme (während Verbuchung A läuft, dürfen manche Prozesse nicht laufen), insbesondere bei Parallelisierung (wg. Speed).
Euer Ansatz mit einer Datei, die Sperren verwaltet ist erst mal OK. Ich würde das allerdings optimieren.
- Sperre setzen durch schreiben eines Sperrsatzes unter commit in einer ACTGRP, die nie commited wird.
- Sperre freigeben durch löschen des Sperrsatze.
- bricht das irgendwo ab, macht die Datenbank einen automatischen Rollback (hackt jemand die Stromzufuhr durch, beim nächsten IPL)
- zentralisiert wird das in einem SRVPGM, das als einziges die Sperrdatei benutzt und dazu aufgerufen wird. Beim CRTSRVPGM ACTGRP(NOCOMMIT) verwenden.
- kann eine Sperre nicht erteilt werden, sendet die entsprechende Procedure eine Abbruchmeldung.
- optional kann man noch einen wait Parameter in die Schnittstelle aufnehmen, bei immed sendet man eine Escape Message - ansonsten blockiert man den aufrufenden Prozess (lässt ihn warten).
Die Sperrdatei wird mit recordwait immed angelegt.
D*B
dschroeder
04-12-23, 09:10
... noch eine Bemerkung zu eurem Sperrverfahren:
Ich würde hier Satzsperren und Prozesssynchronisation gedanklich voneinander trennen. Satzsperren sind kurz andauernd (Milllisekunden) und dienen der Transaktionskontrolle, das macht die Datenbank automatisch und hier dürfen keine lang andauernden (mehar als eine Bildschirmtransaktion) Sperren auftreten.
Prozesssynchronisation benötigt lang andauernde Sperren, bis ein anderer Prozess fertig ist. Hierunter fallen z.B.: Reisebuchungen, Verwaltung von Versicherungsverträgen können dazu gehören, auch Bestellungen mit Reservierungen können dazu gehören; in dieselbe Kategorie fallen auch etliche Batchprogramme (während Verbuchung A läuft, dürfen manche Prozesse nicht laufen), insbesondere bei Parallelisierung (wg. Speed).
Euer Ansatz mit einer Datei, die Sperren verwaltet ist erst mal OK. Ich würde das allerdings optimieren.
- Sperre setzen durch schreiben eines Sperrsatzes unter commit in einer ACTGRP, die nie commited wird.
- Sperre freigeben durch löschen des Sperrsatze.
- bricht das irgendwo ab, macht die Datenbank einen automatischen Rollback (hackt jemand die Stromzufuhr durch, beim nächsten IPL)
- zentralisiert wird das in einem SRVPGM, das als einziges die Sperrdatei benutzt und dazu aufgerufen wird. Beim CRTSRVPGM ACTGRP(NOCOMMIT) verwenden.
- kann eine Sperre nicht erteilt werden, sendet die entsprechende Procedure eine Abbruchmeldung.
- optional kann man noch einen wait Parameter in die Schnittstelle aufnehmen, bei immed sendet man eine Escape Message - ansonsten blockiert man den aufrufenden Prozess (lässt ihn warten).
Die Sperrdatei wird mit recordwait immed angelegt.
D*B
Guten Morgen,
unser Sperrverfahren läuft in etwa so, wie du es skizziert hast, denke ich. Der Satz in der Sperrdatei wird mit einem physischen Lock versehen. Zugegebenermaßen noch mit F-Bestimmung. Es gibt auch nur ein zentrales Tool, das die Sperren verwaltet.