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

[BenderD]

... aber hoffentlich dagegen!
D*B

... und bei Kraut und Rüben hätte dann wohl der Herr Rübenscheid protestiert ...

[dschroeder]

Vielen Dank an euch alle!
Es hat sich ja eine interessante Diskussion entwickelt. Wir werden die gelieferten Erkenntnisse hier im Haus diskutieren und mal sehen, was wir da machen. Wir haben hier ein bestehendes, gewachsenes System, das wir natürlich nicht von Grund auf neu durchstylen können. Wir müssen deshalb Lösungen finden, die bei neuen Programmen und Programmerweiterungen besser sind als die alten Sperrverfahren. Aber trotzdem müssen wir kompatibel bleiben.

Nochmals vielen Dank.
Dieter

[Fuerchau]

Genau diese Kompatibilität ist ja ein Problem.
Arbeitet die alte Anwendung ohne Journalisierung kann man sie nicht oder nur unter größten Schwierigkeiten darauf umstellen.
Dies habe ich auch schon festgestellt.
Das betrifft dann ebenso die Sperrverfahren solange man ja an die alten Dateien auch dranmuss (was ja schon vorkommen soll).
Für neue Dateien und losgelöste Erweiterungen sollte man durchaus auf Journale und Commit zurückgreifen um es eben besser zu machen, wobei gerade das "Besser" sehr unterschiedliche betrachtet wird.
Spätestens wenn man alt und neu mischen muss fangen die Probleme erst richtig an.
Hier muss man sich dann Konstrukte über getrennte ACTGRP's einfallen lassen damit es funktioniert.
Bei ODBC/JDBC geht das wieder nicht innerhalb einer Verbindung (SQL kann erst mal nur 1 ACTGRP), hier benötigt man dann 2 Verbindungen und Framework-Methoden (Offline Resultsets) sowie Connection-Pools bleiben dann erst mal außen vor.

Wir haben vor ein paar Jahren mal ein paar wenige Dateien einer Anwendung journalisiert ohne Commit zu aktivieren. Das Ergebnis war 10GB / Stunde an Journalen neben ein paar Performanceeinbußen!

[BenderD]

Wir haben vor ein paar Jahren mal ein paar wenige Dateien einer Anwendung journalisiert ohne Commit zu aktivieren. Das Ergebnis war 10GB / Stunde an Journalen neben ein paar Performanceeinbußen!

Das müssen aber dann Dateien mit riesigem Transaktionsvolumen gewesen sein und die Platten extrem langsam. Ich habe vor circa 20 Jahren angefangen nach Möglichkeit alle Dateien zu journalisieren (wg. Nachvollziehbarkeit und effektiver Fehleranalyse). Die Performance Auswirkungen waren stets kaum messbar und in der Tendenz wurde es eher minimal schneller (Die Datenbank schreibt die sequentiellen Journale forciert und die Dateien, wenn es ihr langweilig ist). Solche Horrorstories machen immer wieder die Runde, sind aber in den meisten Fällen nicht verifizierbar.
Ich kann nur empfehlen das auszuprobieren und zu messen. Journalisierung hat man in einer Stunde eingerichtet und in 10 Minuten deaktiviert - und an den laufenden Anwendungen ist kein Änderungsbedarf, die merken das nicht einmal!

D*B

[dschroeder]

Es freut mich, dass ich mit meinen "Alltagsproblemen" nicht ganz allein dastehe. Eine theoretisch perfekte Lösung geht meist nur, wenn man auf einer grünen Wiese neu beginnen kann.
Vielen Dank.

[Fuerchau]

Nun ja, die ERP-Anwendung arbeitet aus Sicherheitsgründen (da ja kein Journal läuft) auf jeder Datei mit FRCRATIO(1)!
Bei einigen Batchprogrammen konnte ich Laufzeiten von mehreren Stunden auf wenige Minuten reduzieren in dem ich einfach auf FRCRATIO(*NONE) gestellt hatte.
Bei RAID-Platten macht FRCRATIO(1) auch wenig Sinn.

Die Filehandler arbeiten beim "Lesen ohne Lock" mit CHAIN/UPDATE anstelle mit CHAIN(N), also ob die Programmierer damals (ca. 15 Jahre) das CHAIN(N) nicht kannten.

Batch-Programme, die wenig ändern lesen die Dateien mittels Filehandler mit CHAIN->UPDATE USER/JOBNAME->CHAIN löschen USER/JOBNAME um eben eine logische Sperre zu setzen um vielleicht eine Änderung durchzuführen. Dies führt natürlich zu hohem Journalaufkommen obwohl keine relevanten Daten geändert werden. Auf diese Weise werden komplette Stammdaten zum Teil mehrfach am Tag "geändert" ohne tatsächliche Änderungen durchzuführen.
Diese ERP-Anwendung ist nicht zu modernisieren (Never Change ...) und führt eben zu diesen gigantischen Journalen.

Auch das Datenbankmodell ist natürlich nicht optimiert. So enthalten Stammdatentabellen auch Bewegungsdaten (z.B. Lagerbestand). Hier muss natürlich intensiv über Sperren nachgedacht werden da sich Bestände am häufigsten ändern.
Wie gesagt, alte Anwendung die aber stabil läuft.

[BenderD]

... wenn die Maschine nicht genauso alt wie die Software ist, sind weder die 10 GB/Stunde ein Problem, noch die Workload der Journalisierung. Selbst wenn man zusätzliche Platten kaufen müsste, wäre das Geld dafür bei der ersten Fehlersuche wieder drin.

D*B

[dschroeder]

Ich möchte nur kurz sagen, dass wir das passende API gefunden und für uns gekapselt haben:


**-- API Prototype: Get list of jobs for record lock --------------**
D RtvRcdLck PR extpgm('QDBRRCDL')
D RlJobList like(JobListDS)
D RlJobListLen 10I 0 const
D RlApiFmtName 8A const
D RlQulFileName 20A const
D RlMbrName 10A const
D RlRrn 10U 0 const
D RlErrRtn like(ApiErrorDS)

Das API liefert eine Liste der Jobs, die eine Satzsperre auf dem zu prüfenden Satz halten oder die auf eine Sperre warten.
Läuft sehr gut und schnell. Wenn man das API benutzt, muss man die Satzwartezeit nicht einstellen. Das Ergenis kommt sofort (ist ja auch klar, denn man macht ja keinen chain).

Wir haben das bei uns jetzt in etwa so eingesetzt:

if not isLocked('KUNDENDAT':satznr);
chain(e) kundendatei ...
...

Die isLocked Funktion bringt dann auch gleich eine Meldung, welcher Mitarbeiter den Datensatz sperrt.

Dieter

[Fuerchau]

Ohne API (auch gekapselt) kann man nur mit DB's Sperrdatei sicher und auch vielfältiger arbeiten.
Man nehme eine neue Datei mit Unique-Key und z.B. JOB-Infofeldern.
Packe die Sperrfunktionen in ein Service-Programm mit eigener ACTGRP.
Nun kannst du lustig beliebige Exklusiv-Sperren setzen:

Z.B.
if Sperre(Key) = *on;
// tuwas
Entsperre(Key);
endif;

Das Serviceprogramm startet ggf. eine eigene Commit-Definition.

In der Funktion Sperre wird:
per Insert versucht den Satz zu schreiben (JobInfos ohne API aus INFDS)!

Schlägt der Insert fehl (duplicate Key ist schneller als jedes API) kann man per Select die Jobinfos auslesen und entsprechende Meldung ausgeben.
Hier kann ggf. auch noch der eigene Job drinstehen, dann gilt die Sperre ja auch noch.
Ist beim Select der Satz nicht mehr da, kann man den Insert wiederholen.
Dies passiert so lange (meist max. nur 2 Mal) bis der Insert oder Select OK ist.

Ist der Insert OK, ist die Sperre erhalten.

In der Funktion Entsperre() wird der Satz wieder gelöscht.

Da das Service-Programm keine Commit/Rollbacks ausführt, werden bei Jobende automatisch alle Sperren gelöscht (Auto-Rollback).

Dies hat den Vorteil, dass man
a) ggf. mehrere Sätze aus einer Datei sperren kann (ohne einen Update zumachen oder den Commit-Level höher zu setzen).
b) Sperren anfordern kann, die nichts mit Dateien zu tun haben (was gerne mit DTAARA's gelöst wird).

Zu b)
Dies ist ja häufiger bei Batchprozessen nötig die sich ggf. gegenseitig ausschließen.
Man kann auch dann mittels DLYJOB etwas länger auf die Sperren warten wenn es denn erforderlich ist.

Die Sperre/Entsperre-Funktion lässt sich auch als SQL-Procedure kapseln.
Die separate ACTGRP hilft auch im QZDASOINIT-Job.
Genauso gut lassen sich hier für CLP's auch CMD's wie LOCKKEY KEY(ABCD) und UNLOCKKEY KEY(ABCD) entwickeln.

So können nun SQL-Clients und CLP's ebenso diese Funktionen nutzen.

Natürlich kann man mit Native-SQL's sowieso an der Anwendung vorbei arbeiten, aber die API-Lösung verhindert das ja auch nicht.

[dschroeder]

Die API-Funktion prüft ja auf "physische" Sperre durch die Datenbank. Da kommt man auch mit SQL nicht dran vorbei. Ich gebe zu, die Lösung mit den logischen Sperren hat den Vorteil, dass man problemlos mehrere Sperren in der gleichen Datei setzen kann. Die Problemstellung hatte ich jedoch noch nicht.

Ich denke, wir werden erstmal (auch mit Hinblick auf ältere Programme) weiter mit physischen Sperren arbeiten. Das API hilft uns dabei, solche Sperren zu erkennen, bevor ein Chain versucht wird und schiefgeht.

Dieter.

[BenderD]

... da geht ja wieder einiges durcheinander:
- mit dem API bleibt der Designfehler, dass damit nicht zugleich eine eigene Sperre angefordert wird
- die Prüfung kann frei ergeben und der Job blockiert trotzdem 60 sec, weil ein anderer dazwischen gerutscht ist
- Datenbanken setzen immer physische Sperren für updates
- das zugrunde liegende Problem, dass der Benutzerprozess Sperren hält und die Kontrolle bekommt bleibt bestehen - dieser Anfängerfehler gehört behoben, gerade wenn man die "Altanwendung" weiter braucht und benutzt.

D*B

[dschroeder]

... da geht ja wieder einiges durcheinander:
- mit dem API bleibt der Designfehler, dass damit nicht zugleich eine eigene Sperre angefordert wird
- die Prüfung kann frei ergeben und der Job blockiert trotzdem 60 sec, weil ein anderer dazwischen gerutscht ist
- Datenbanken setzen immer physische Sperren für updates
- das zugrunde liegende Problem, dass der Benutzerprozess Sperren hält und die Kontrolle bekommt bleibt bestehen - dieser Anfängerfehler gehört behoben, gerade wenn man die "Altanwendung" weiter braucht und benutzt.

D*B

Danke für die Antwort.
Die (minimale) Unsicherheit, dass jemand dazwischenrutscht, ist mir bewusst. (Ich hatte vorher schon geschrieben, dass das in unserem Fall kein Problem ist). Auf jeden Fall werden wir mit der neue Prüfung per API deutlich besser, als wenn wir die User bei jeder Sperre in den 60-Sekunden Wartezustand laufen lassen.

Desweiteren hattest du ja bereits früher geschrieben, dass alle Sperren aufgehoben sein sollten, wenn die Kontrolle an den User zurückgeht. Das ist aber doch nur eine Meinung (nämlich deine). Ich finde nicht, dass das eine allgemeingültige Weisheit ist. Wenn ich den ganzen Forumsthread Revue passieren lasse, meine ich, dass die meisten der Meinung sind, dass sie physiche Sperren ablehnen und stattdessen logische Sperren setzen würden. Das funktioniert selbstverständlich, ist aber meiner Ansicht nach nicht der einzige Weg. Ich sehe immer noch kein Problem bei physischen Sperren. Ein Umbau auf ein vollständig transaktionsgesteuertes Verfahren mit Commitmentt Control kann ich mir bei uns im Hinblick auf die bestehende Anwendung nicht vorstellen.

Dieter