Wie bekomme ich Record-Locking mit embedded SQL hin?

[prsbrc]

Ich hab es auch mal probiert da unser Kundenstamm hier auch mittels CHAIN-Lock den Satz sperrt.
Es funktioniert per SQL (SELECT/UPDATE) mit RS.
Da bleibt der Satz bis zum COMMIT/ROLLBACK gesperrt.

[BenderD]

Ich hab es auch mal probiert da unser Kundenstamm hier auch mittels CHAIN-Lock den Satz sperrt.
Es funktioniert per SQL (SELECT/UPDATE) mit RS.
Da bleibt der Satz bis zum COMMIT/ROLLBACK gesperrt.

... das Problem dabei ist, dass die Sperre einen konkurrierenden update verhindert, aber den eigenen Update noch nicht ermöglicht. Für den update wird dann versucht, die Sperre zu eskalieren, was bei konkurrierendem Zugriff dazu führt, dass der erste Anforderer abbricht.

D*B

[Fuerchau]

Wobei der Abbruch auch noch 1 Minute dauert.
D.h., im Dialog erfährt der User erst nach 1 Minute, dass da ein Lock besteht.
Besser ist da schon die Job-Prüfung, was ja nun auch via SQL geht.

[BenderD]

Wobei der Abbruch auch noch 1 Minute dauert.
D.h., im Dialog erfährt der User erst nach 1 Minute, dass da ein Lock besteht.
Besser ist da schon die Job-Prüfung, was ja nun auch via SQL geht.

... dass der Abbruch eine Minute dauert, liegt allerdings an den idiotischen defaults der Einstellungen der Dateien. Waitfile steht hier auf *immed und waitrcd auf 60 Sekunden, hier müssen die Jungs und Mädels bei IBM Stunden beieinander gesessen haben und intensiv an Nichts gedacht haben. Waitfile * immed führt dazu, dass das commit level serializable (das der SQL Standard als Unterlassungswert fordert) mit recor level access unvereinbar ist. Datensätze, die langer als Millisekunden dauern, werden auch in Minuten nicht frei: Der Benutzer eines schadhaften Programms hat einen Satz gelesen und ist in die Mittagspause gegangen.
Diese unsinnigen Einstellungen ließen sich korrigieren, für WAITRCD wäre 1 Sekunde angemessen und WAITFILE sollte in jedem Fall größer als WAITRCD sein. Man kann dies allerdings per OVRDBF für das jeweilige Programm anpassen. Für Dialogprogramme auf *IMMED oder die oben gennante 1 sec (wenn man sich nicht traut) und für Synchronisatiuonszwecke von Batchjobs auf *NOMAX (das ist besser als in Schleife warten und neu versuchen, spart Strom und verhindert, dass ein anderer reinrutscht).

Dein Vorschlag mit der Job-Prüfung ist m.E. nur der zweitbeste Weg; genauer (wie der Schachspieler sagen würde) ist, den zu sperrenden Satz ohne zu lesen sofort zu ändern, bzw. zu schreiben.
Der Unlock erfolgt dann durch ROLLBACK oder COMMIT und der nächste wartende Job läuft automatisch an.

D*B

PS: Bei *NOMAX Wartezeiten muss man sorgfältig auf Deadlock Vermeidung achten, was auch für Warteschleifen gilt.

[Fuerchau]

Es gibt schon mal Transaktionen, die länger als 1 Sekunde dauern, i.d.R. aber selten länger als 20-30 Sekunden. Um den Betrieb nicht zu stören, ist eine Wartezeit weniger als 30 Sekunden nicht so empfehlenswert.

Die "Belegsperre" läuft in einer eigenen ACTGRP um eben gegen übergeordente Commits im Job gefeit zu sein.
Auch das Halten von Locks hat sich als ungünstig erwiesen, daher die Lösung mit der Job-Info, wer der Halter des logischen Locks ist.

Dadurch kann auch bei Nichterhalten des Locks eine Nachricht über den Halter ausgegeben werden. Dies ist bei regulären Locks halt nur mit Schwierigkeiten (Lock-API's) heraus zu finden.
Während der logischen Sperre eines Beleges erfolgen über einen Dialog durchaus mehrere Transaktionen was zur Folge hätte, dass die physischen Locks gelöst würden.

Meine oben beschriebene Lösung ist nun seit fast 3 Jahren erfolgreich bei einem Kunden im Einsatz und hat viele Probleme gelöst. Und sie ist unabhängig von der Satzwartezeit;-).