Herausfinden, ob ein Datensatz gesperrt ist und welcher User den Satz sperrt

[Fuerchau]

Hier das API für die Lock's.
http://www-01.ibm.com/support/knowle...s/qdbrrcdl.htm
Allerdings musst du schon mal einen CHAIN(N) machen und über die INFDS die Satz-Nr. ermitteln, die durch einen anderen Job (siehe API) gesperrt sein könnte.

[BenderD]

... wenn Satzsperren länger als Millisekunden dauern, dann ist am Design was krumm; das gehört an der Ursache kuriert, statt am Symptom rumzudoktern. Was den Record wait angeht, da müssen die in Rochester volltrunken gewesen sein: 60 sec versus Filewait *immed! angemessen sind hier max. 2 sec. bis 5 sec. für den Satzwait und Datei wait > Satz wait.

D*B

[dschroeder]

... wenn Satzsperren länger als Millisekunden dauern, dann ist am Design was krumm; das gehört an der Ursache kuriert, statt am Symptom rumzudoktern. Was den Record wait angeht, da müssen die in Rochester volltrunken gewesen sein: 60 sec versus Filewait *immed! angemessen sind hier max. 2 sec. bis 5 sec. für den Satzwait und Datei wait > Satz wait.

D*B

Das Satzsperren nur kurz sein dürfen, halte ich nicht in jedem Fall für richtig. Wenn ich einen Kunden editiere, muss der solange gesperrt werden, bis ich fertig bin. Ich möchte nicht, dass mir das Programm beim Speichern sagt: "Sorry, der Satz wurde bereits von jemand anderem upgedatet. Mach deine Änderung nochmal!"

Dieter

[dschroeder]

Noch eine andere Frage im Zusammenhang mit Record-Locks: Ich könnte mir gut ein Tool vorstellen, das alle Satzzugriffe für mich macht. Wir arbeiten viel mit extern beschriebenen Datenstrukturen.

Wenn ich also eine Datenstruktur habe, die einen Kunden repräsentiert, könnte ich mir folgendes Tool vorstellen:
// Das Tool sperrt den Datensatz und gibt die gefüllte Struktur zurück:
if accessKunde(KUNDESatz:'*LOCK');
...

// Später wird gespeichert und der Satz wieder freigegeben:
accessKunde(KUNDESatz)

Die Frage ist, wie "lange" so ein Tool die Sperre hält. Wenn ich zwischendurch ein anderes PGM aufrufe, das ebenfalls mit diesem Tool einen (anderen) Kunden per Record-Lock holt, würde das Tool die erste Sperre ja aufheben. Ich bin mir nicht sicher, ob das praktikabel ist.
Nutzt ihr so etwas?

Dieter

[Fuerchau]

Es gibt da manche Anwendungen die ein bis ein paar Felder in einer Tabelle für logische Sperren vorhalten. Beim Sperren wird User/Workstation eingetragen beim Entsperren wieder gelöscht.
Alle Zugriffe werden über FileHandler durchgeführt, die dann automatisch Sperren prüfen.
Es funktioniert ja auch meistens, allerdings benötigt man dann Reorgs, die verwaiste Sperren wieder aufheben.

Arbeitet man mit Satzsperren ist es natürlich klar, dass diese aufgehoben werden wenn ein anderer Satz über den Handler gelesen wird.

Beim Update wird der Satz im Handler erst noch mal über eine 2. Struktur gelesen und dann der Update durchgeführt. Eine Prüfung, ob sich zwischenzeitlich was geändert hat erfolgt nicht.
Das Ganze System funktioniert, wenn sich alle an die Handler halten.

Was das API angeht so kannst du Satzsperren nach Rel.Satz-Nr. filtern, das geht dann schnell und liefert max. einen Job. Zur Ermittlung der Satz-Nr. benötigst du aber trotzdem einen Chain(N) (N=No Lock) und die Infds.

[BenderD]

Alle Zugriffe werden über FileHandler durchgeführt, die dann automatisch Sperren prüfen.
Es funktioniert ja auch meistens, allerdings benötigt man dann Reorgs, die verwaiste Sperren wieder aufheben.

Auch das ist bei richtiger Implementierung unnötig, unter Commitment Controll verschwinden diese Kennzeichen mit dem Rollback, der im Fehlerfall (Absturz etc.) automatisch hinterherkommt. Gelesen wird dann von anderen Programmen für das Subfile mit uncommited read (keine Sperranforderung beim lesen), die Verarbeitung ist dann über das Sperrkennzeichen geblockt.

Für Härtefälle gibt es dann noch ILE Exit Handler, die bei ENDACTGRP aufgerufen werden - wenn man die Aufräumarbeiten da reinpackt, dann räumt sich das zuverlässig weg, auch bei Programmabstürzen und irregulärer Beendigung von Jobs.

D*B

[dschroeder]

Es gibt da manche Anwendungen die ein bis ein paar Felder in einer Tabelle für logische Sperren vorhalten. Beim Sperren wird User/Workstation eingetragen beim Entsperren wieder gelöscht.
Alle Zugriffe werden über FileHandler durchgeführt, die dann automatisch Sperren prüfen.
Es funktioniert ja auch meistens, allerdings benötigt man dann Reorgs, die verwaiste Sperren wieder aufheben.

Arbeitet man mit Satzsperren ist es natürlich klar, dass diese aufgehoben werden wenn ein anderer Satz über den Handler gelesen wird.

Beim Update wird der Satz im Handler erst noch mal über eine 2. Struktur gelesen und dann der Update durchgeführt. Eine Prüfung, ob sich zwischenzeitlich was geändert hat erfolgt nicht.
Das Ganze System funktioniert, wenn sich alle an die Handler halten.

Was das API angeht so kannst du Satzsperren nach Rel.Satz-Nr. filtern, das geht dann schnell und liefert max. einen Job. Zur Ermittlung der Satz-Nr. benötigst du aber trotzdem einen Chain(N) (N=No Lock) und die Infds.

So einen selbstgebauten Sperrmechanismus haben wir für bestimmte Bereich auch implementiert. Ich würde gerne die von der Datenbank gehaltene "physische" Sperre erkennen.

Ich halte physische Sperren für sicherer, weil dann auch Zugriffe per SQL verhindert werden.

Ich werden mir die APIs mal anschauen.

Vielen Dank an alle.
Dieter

[BenderD]

Ich halte physische Sperren für sicherer, weil dann auch Zugriffe per SQL verhindert werden.

... wenn man natürlich den Empfehlungen mancher hier folgt und bei SQL mit commit level *NONE arbeitet, dann ist Hopfen und Malz verloren...

Mal ganz abgesehen davon, dass das mit dem API nicht funktioniert:
- gucken mit API, keine Sperre da
- rein in die Verarbeitung: Mist geht doch nicht, ein anderer war schneller 60 sec. blockiert
oder:
- gucken mit API, Sperre da Benutzre XYZ
- den angerufen, der ist aber längst fertig, aber ein anderer hat jetzt angefangen
... vielleicht gut fürs Betriebsklima, da reden Leute wenigstens miteinander...

D*B

[dschroeder]

Wenn ich Sperrungen nur logisch setze, würde ein manuell abgesetztes SQL (z.B. aus dem Navigator heraus) das ja nicht bemerken. Ich müsste dann auch noch bei jedem SQL unsere logische Sperre mitselektieren. Bei physischen Sperren kann ich das jedoch einfach in einer where Klausel machen.
Dieter

[BenderD]

Wenn ich Sperrungen nur logisch setze, würde ein manuell abgesetztes SQL (z.B. aus dem Navigator heraus) das ja nicht bemerken. Ich müsste dann auch noch bei jedem SQL unsere logische Sperre mitselektieren. Bei physischen Sperren kann ich das jedoch einfach in einer where Klausel machen.
Dieter

... auch hier heißt das Zauberwort: View Layer (auf das Physical Layer darf per SQL default keiner drauf).

[dschroeder]

Hier im Hause sprechen wir natürlich im Moment nur über statefull Anwendungen. Wenn ich Birgitta richtig verstehe, kann es bei Verwendung von Commit Control und physischen Sperrungen zu nicht auflösbaren Deadlocks kommen? Das wäre natürlich in der Tat ein echtes Argument gegen physische Sperren.
Die Sache mit dem feldweisen Vergleich ist mir noch ein wenig suspekt. Wenn 2 user gleichzeitig verschiedene Felder im gleichen Datensatz ändern und ich das dann feststelle und (da es ja keine Konflikte gibt), die Feldänderungen beider user speichere, heißt das ja noch lange nciht, dass der so aktualisierte Datensatz dann noch logisch in Ordnung ist! Die Anwendung hätte ja vielleicht verhindert, dass die Feldänderung von User 2 gemacht werden, wenn sie gewusst hätte, welche Felder User 1 geändert hat.

Dieter

[BenderD]

Wenn ich Birgitta richtig verstehe, kann es bei Verwendung von Commit Control und physischen Sperrungen zu nicht auflösbaren Deadlocks kommen?

... auch Deadlocks sind bei richtiger Vorgehensweise vermeidbar: Transaktionen müssen ihre Ressourcen in festgelegter Reihenfolge holen (siehe auch dining philosophers problem).

D*B