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

[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

[BenderD]

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.

... sowas kann Stunden dauern, wenn das bei euch tolerierbar ist, na dann tut es vielleicht auch MS-Access ...

D*B

[dschroeder]

... sowas kann Stunden dauern, wenn das bei euch tolerierbar ist, na dann tut es vielleicht auch MS-Access ...

Coole Idee ... dann hätten wir ja auch direkt eine grafische Oberfläche ...

[Fuerchau]

Die Satzsperren-Problematik betrifft ja (im Wesentlichen) nur Anwendungen mit RLA (Zugriffe ohne SQL).
Die "reine" SQL-Fraktion kennt natürlich auch Sperren, diese sind im Normalfall aber erst nach Update/Insert aktiv und werden automatisch bei Commit/Rollback aufgehoben.

Der Select kennt im Normalfall keine Sperre.
(Ja ich weiß, es gibt den "Select for update", den man aber vermeiden sollte.)

Die Regel beim SQL-Update besteht im erweiterten Where:
Update mytable set value=: newvalue where key=: mykey and value = : oldvalue;
der Update schlägt fehl und der User bekommt einen Hinweis.
Dies ist insoweit interessant da updates unterschiedlicher Felder durch unterschiedliche User dann nicht zum Fehler führen (soweit man nicht mit "Select *" arbeitet) .

Nun muss man noch unterscheiden zwischen Absolut-Updates und Relativ-Updates.
Absolut-Updates " Value = Newvalue" sind sicherlich ein Problem.
Aber Relativ-Updates sind eher unproblematisch " Value = Value + : NewValue".

Darauf ist auch das Design einer Anwendung anzuwenden. Dann kommt man auch ohne Sperren aus.

Bei Stammdaten gibt es aber auch ähnliche Risiken. Man nehme nur das Problem der Dublettenprüfung. Hier helfen keine Satzsperren da die Prüfung ja erst nach Insert stattfinden kann. Findet die Prüfung vor Insert statt gibt es ggf. doch Dubletten wenn 2 Inserts passieren.

In Frameworks (z.b. ADO.NET) wird dies ebenso behandelt da hier i.W. eine Offline-Bearbeitung ganzer Datasets möglich ist, die dann halt beim Update entsprechende Fehleraussagen treffen.
Durch Journalisierung minimiert sich der Programmieraufwand aber gewaltig.