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

[dschroeder]

Hallo,
kennt jemand eine Möglichkeit, herauszufinden, ob ein bestimmter Datensatz gesperrt ist und falls ja, welcher User oder Job den Datensatz sperrt?

Ich meine jetzt nicht die Möglichkeit, einen Chain zu probieren und dann zu warten, ob das gut geht. Das dauert mir zu lange. Da müsste ich dann erst per OVRDBF die Satzwartezeit temporär herunterdrehen. Das finde ich unschön. Vor allem würde es mir ja nicht sagen, wer den Satz sperrt.

Ich dachte da an ein API, mit dem man vor dem chain prüfen kann, ob der Satz frei ist. Und vielleicht gibt es ja noch ein 2. API, mit dem man prüfen kann, durch welchen User ein bestimmter Datensatz gesperrt ist.


Danke im Voarus.

Dieter

[Fuerchau]

Dies ist sicherlich per API möglich.
Hierfür brauchst du die JOBAPI's, USRSPC-API's und irgendwo die Lock-API's.
Das Problem ist nur, dass du bei deiner Prüfung ggf. langsamer bist als das System.
D.h., du glaubst der Satz ist frei, bis deine Prüfung aber durch ist ist der Satz schon wieder gesperrt.

Wer eine Satzsperre hält erfährst du per SDS nach dem Chain:
https://www.google.com/url?q=http://...VYhGeWja836dLw

[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]

Vielen Dank.
Das API habe ich mir auch schon mal angesehen. Das sieht auf den ersten Blick für mich so aus, als würde damit eine Liste der Record-Locks angezeigt. Vielleicht gibt es ja noch ein API, dass mir für genau einen Satz anzeigt, ob der Satz gesperrt ist. Sonst müsste ich die Liste durchgehen.

Das Problem mit der Restunsicherheit (Ich prüfe und bevor ich wirklich sperre, hat das System schon eine Sperre gesetzt, ist mir bewusst. Das macht in meinem Fall aber keine Probleme).

Das mit dem Chain und der PSDS ist prizipiell in Ordnung. Aber der Chain dauert ja solange, wie die Satzwartezeit ist. Ich müsste also erst ein Ovrdbf machen und die Satzwartezeit auf *IMMED setzen, damit die Sperre sofort reagiert. Das wollte ich eigentlich vermeiden. Deshalb war ich auf der Suche nach einem API, das mir einfach zurückgibt, ob ein bestimmter Satz gerade gesperrt ist.

Dieter

[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]

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

... länger andauernde Bearbeitungen über Record Locks abzubilden ist ein ernsthafter Kunstfehler, da sind andere Implementierungen vorzuziehen. Record Locks sind dafür da Transaktionen abzbilden (siehe auch Commitment Controll).


PS: Das mit dem einen Programm, das alle Dateien liest ist auch so eine typische RPG Programmierer Idee. Best Practice ist: für jede Datei genau ein Modul, das allein verantwortlich für alle Zugriffe auf diese Datei ist und diese ausschließlich über Views macht. Da früber gibt es dann ein Modul, das Transaktionen kann und von der Business Schicht für den Zugriff auf Dateien verwendet wird.

D*B

[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]

... länger andauernde Bearbeitungen über Record Locks abzubilden ist ein ernsthafter Kunstfehler, da sind andere Implementierungen vorzuziehen. Record Locks sind dafür da Transaktionen abzbilden (siehe auch Commitment Controll).
D*B

Tut mir leid, aber ich kann nicht nachvollziehen, wieso eine Implementierung besser ist, die einem User das Editieren eines Datensatzes erlaubt, ohne dass sie sicherstellen kann, dass er das dann später auch speichern kann. Ein Rollback räumt doch nur auf. Der User, dessen Änderungen nicht gespeichert werden können, hat davon erstmal nichts.

Dieter

[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