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]

... 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

[B.Hauser]

Wenn die Transaktion (also mehrere Updates etc unter Commit läuft) kommt und der Satz unter commit gesperrt ist, kann niemand und nichts außerhalb der Transaktion den Satz oder die gelockten Sätze ändern, weder SQL noch native I/O noch updta, noch was auch immer. Abhängig vom Commitment level können u.U. geänderte und neu geschriebene Datensätze "gesehen" bzw. gelesen werden.

Einen Satz zu sperren und so lange gesperrt zu halten bis die Änderungen "eingegeben" sind, mag ja bei klassischen Green Srceen-Anwendungen funktionieren, .... versuch das gleiche mal in einer Web-Anwendung (Stichwort stateless!)

Wenn Du entsprechende Update-Module wie Dieter vorgeschlagen hat generierst, kannst Du u.U. auch einen Abgleich (ursprünglicher Satz, geänderter Satz, aktueller Satz) auf Feld-Ebene integrieren und die aktuellen Daten so anpassen, d.h.
Original = Änderung = Aktuell --> Feld bleibt
Original <> Änderung und Aktuell = Original --> Änderung
Orginal = Änderung jedoch ungleich Aktuell --> Aktuell
Original <> Änderung <> Aktuell --> Änderung

Damit können "Update"-Probleme auf ein Minimum reduziert werden.

Das ist zwar liebevolle Kleinarbeit, wird jedoch pro Datei/Tabelle nur einmalig kodiert und für alle Änderungen in der Datei verwendet.

Birgitta