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

[malzusrex]

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

hmm, ich kann doch nix dafür...

Gruß
Ronald Malz

[Tschabo]

Hallo Dieter,

ich kenne folgende Möglichkeit über die Programminformationsdatenstruktur

* --------------------------------------------------------------
* Programminformationsdatenstruktur
* --------------------------------------------------------------
D psds SDS
D excp_data 91 170

C ky_sfl001pf CHAIN(E) sfl001pf

* Fehler beim CHAIN
C IF %ERROR = *ON
* Auf Satzsperre abfragen
C IF %STATUS = 01218
* Das Feld <> hat folgenden Inhalt:
* Satz 11 wird von Job 764835/TSCHABO/QPADEV002F benutzt.
C ENDIF

Vielleich hift dass ja weiter.

Gruß
Tschabo

[Fuerchau]

Die Fragestellung war ja, die Sperre zu prüfen bevor sie auftritt.
Die kürzeste Wartezeit bei Satzsperren ist aber bereits 1 Sekunde was manchem zu lang ist und ggf. bei größeren Transaktionen mit Commit wieder zu kurz sein kann.

[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

[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

[BenderD]

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

... habe ich nie behauptet. Länger andauernde Sperren werden logisch gesetzt (siehe Baldurs Ausführungen). Wenn ich das unter Commit mache, verschwinden die mit einem automatischen Rollback, wenn das Programm abschmiert. Programmiere ich in der Oberliga, kann ich über ein Notify Object oder eine Transaction Monitor wie CICS (was ist das denn schon wieder?) den Benutzer der abgeschmierten Session bei Wiederanmeldung das wieder anbieten (so ähnlich wie bei abgeschmierten Editor Sitzungen).

D*B

[Robi]

Wir machen ähnlich der von Dieter beschriebenen Methode. Nur das wir selten Views lesen

Je PF, je LF fällt ein Lesepgm (u.v.m) aus unserem Generator
(unsere Lese Pgmme können auch schreiben, das ist performanter)
Jeglicher Dateizugriff MUß über diese Pgmme erfolgen.
Fehlersuche damit recht einfach, debug, breakpoint setzen warten und stapel ansehen
Sperre händling:
- Weiche Sperren,
-- Sind diese gewünscht : update des Satzes mit Jobnr in ein Feld,
ist Jobnr belegt, dann Satz gesperrt --> Job-Info an den rufenden job

- Harte sperren
-- nur wenn eine Nr sich hochzählt. Das machen die Pgmme alleine
(über automatich eingebundene /copy via Namensregel)

Dazu SEU Erweiterungen die den nötigen code zum lesen / Schreiben / fehlerhändlichg eingenerieren. Diese sehr komfortablen SEU-Erweitrungrn sind der Grund das wir noch nicht mit RDI (o.wie das grade heist) arbeiten

viel Erfolg!
Robi

[Robi]

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

Uns wurde vor gefühlten 100 Jahren schon beigebracht:
Wenn Zugriffe auf die Daten außerhalb der WaWi (heute ERP) nötig sind ist die WaWi mist!

Das können wir zwar nicht immer einhalten, finde die Grundidee abr klasse!
Was sprich gegen ein "and XXXjobnr = 0" in allen SQL's?

[dschroeder]

Uns wurde vor gefühlten 100 Jahren schon beigebracht:
Wenn Zugriffe auf die Daten außerhalb der WaWi (heute ERP) nötig sind ist die WaWi mist!

Das können wir zwar nicht immer einhalten, finde die Grundidee abr klasse!
Was sprich gegen ein "and XXXjobnr = 0" in allen SQL's?

Erstmal Danke für die Antwort.

Mir wäre es auch lieber, wenn wir nie von außen an die Datenbanken müssten. Leider lässt sich das nicht vermeiden.

Aber zu deinem "Was spricht gegen ein "and XXXjobnr = 0" in allen SQL's?" Da könnte ich genauso gut fragen: Warum baut ihr eine Sperrlogik selber, die die Datenbank doch schon mitbringt? Ihr wollt ja sperren. Sonst würdet ihr ja keine "weichen" oder "harten" Sperren implementieren. Wenn ihr also sperren wollt: Warum wollt ihr dann, dass eine gesetzte Sperre nicht wirkt? Was anderes ist es meiner Meinung ja nicht, wenn einem eine physische Sperre "zu hart" ist. Es kann aus meiner Sicht nur einen Grund geben: Ihr wollt die gesetzte Sperre im Notfall umgehen können. Bei einer "sauberen" Anwendung dürfte das ja nie passieren. Und in einem Notfall könnte ich einen Job (i.d.R eine interaktive Sitzung), der eine physiche Sperre hält, beenden. Dann ist die physische Sperre weg.

Dieter

[BenderD]

Erstmal Danke für die Antwort.

Mir wäre es auch lieber, wenn wir nie von außen an die Datenbanken müssten. Leider lässt sich das nicht vermeiden.

Aber zu deinem "Was spricht gegen ein "and XXXjobnr = 0" in allen SQL's?" Da könnte ich genauso gut fragen: Warum baut ihr eine Sperrlogik selber, die die Datenbank doch schon mitbringt? Ihr wollt ja sperren. Sonst würdet ihr ja keine "weichen" oder "harten" Sperren implementieren. Wenn ihr also sperren wollt: Warum wollt ihr dann, dass eine gesetzte Sperre nicht wirkt? Was anderes ist es meiner Meinung ja nicht, wenn einem eine physische Sperre "zu hart" ist. Es kann aus meiner Sicht nur einen Grund geben: Ihr wollt die gesetzte Sperre im Notfall umgehen können. Bei einer "sauberen" Anwendung dürfte das ja nie passieren. Und in einem Notfall könnte ich einen Job (i.d.R eine interaktive Sitzung), der eine physiche Sperre hält, beenden. Dann ist die physische Sperre weg.

Dieter

Es gibt da eine einfache eiserne Regel: Eine Benutzertransaktion klammert immer eine Datenbanktransaktion! Sprich: wenn der Benutzer die Steuerung an das Programm zurückgibt, gibt dieses als erstes alle Satzsperren frei. Wenn ich denn nun länger dauernde Transaktionen habe, komme ich um logische Sperren nicht drumherum (das kann man sich gut an einem Flugreserverungssystem klar machen). Bei Lichte betrachtet gibt es von letzterer Sorte nicht viele Anwendungsfälle, meist steckt da krummes Anwendungsdesign dahinter (siehe Dein Beispiel mit dem Kundensatz!).

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