[Allegro] update.job + optsget.inc überarbeitet

[Bernhard Eversberg]

Hallo Herr Berger,

besten Dank für die erschöpfende und wertvolle Analyse der für das
Speichern relevanten Aspekte.

Wir haben jetzt alle Prozeduren nochmals im Quellcode untersucht,
auf Ihre Bedenken hin abgeklopft und die Vorgehensweise nochmals neu
durchdacht. Was dabei rausgekommen ist, erläutern wir am besten anhand
des Fazits, das Sie am Ende Ihrer Analyse ziehen:

 > Fazit: Ohne Wissen um die *vorgeschriebene* (= von allen Anwendungen
 > einzuhaltene und auch eingehaltene) Reihenfolge bei der Erlangung von
 > Satz- und Datenbanklocks gibt es keine wirkliche Sicherheit.

Sie meinen, der Anwender kann sich ohne dieses Wissen nicht sicher
*fühlen.*
Das Wissen oder Nichtwissen ist es hier nicht, was Sicherheit *schafft*,
sondern ob die Prozeduren stimmig sind. Aber das ist spitzfindig.

 > Mir scheint aber ein hier nicht implementierter Ansatz mit fruehem
 > "get edit",
Was hier früh genug wäre, ist unklar und auch nicht leicht für
alle denkbaren Fälle spezifizier- und verallgemeinerbar. Aber nicht
weiter wichtig, s.unten.

 > moeglichst vielen Manipulationen
Sie meinen wohl, daß anschließend beliebig viele Manipulationen
statthaft sein sollen?

 >  und anschliessendem
 > "set tbl lock" nur im Fall einer zugeschalteten Parameterdatei,
Was täte denn diese dabei zur Sache?

 > ansonsten einfachem "put" (mit implizitem "set rec fre") der
 > Ressourcenschonendste Weg, auch wenn dafuer mehrfach in der .cLD-
 > Datei herumgeschrieben wird.

Beim "put" wird stets, wenn es denn zugelassen wird, das erste
Byte mit 1 überschrieben, und das ist die Freigabe.

Aber insgesamt haben wir erkannt, daß eigentlich im  update.job
weniger Aufwand getrieben werden muß mit dem Locking, als wir dachten.
Dazu folgendes:

Wie Sie hervorgehoben haben, ist es unbefriedigend, daß man
nur mittels  "set lock"  ein sicheres Schreiben vorbereiten kann,
und wenn man dies vergißt, die veränderten Schlüssel nicht
korrigiert werden.
Das muß geändert werden. Wir spalten den Vorgang ab: Jedes Laden
eines Satzes ermittelt sofort die zugehörigen Schlüssel, ob nun
hernach ein Speichern erfolgt oder nicht. Das kostet keine Server-
leistung und keine extra Zugriffe, denn das kann acon alleine.

Der Job sollte direkt vor dem Speichern prüfen, ob gerade eine
Sperre besteht. Wenn ja, ist es unentscheidbar, wie lange diese
bestehen wird. Nur eine (einstellbare?) Anzahl Sekunden sollte
abgewartet werden, dann der Fall protokolliert und zum nächsten
Satz übergegangen.

Um die Sperre von .tbl und Satz zu den kritischen Zeiten kümmert
seit je sich der Vorgang hinter "put" selber, wobei die .tbl nur
dann kritisch ist, wenn es um die interne Nummernvergabe geht.
Diese Sache kommt also wieder raus aus update.job.

Eine Satzsperre wird sodann im Job nicht gesetzt! Denn:
"put" vergleicht vor dem Speichern das Änderungsdatum, und dies
ist der entscheidende Punkt für die Schreibsicherheit:
Ist dieses nicht mehr identisch mit demjenigen zum Zeitpunkt des
Einlesens im Job, wird das Speichern verweigert. Im Job kann dies
bemerkt werden und der Satz daraufhin in die Protokolldatei
geschrieben, die man daher tunlichst am Ende auf solche Fälle hin
betrachtet. Dies aus der Überlegung heraus, daß man sicher *nicht*
ganz allgemein entscheiden kann, ob ein während des update-Vorgangs
genau zu der Zeit anderweitig geänderter Satz überschrieben
werden soll oder nicht! acon wird dann also wie a99 verfahren, nur
daß es keine Konsolmeldung gibt mit Abwarten, was der Operator
entscheidet - genau das geht ja nicht - sondern eben Protokollieren
des Sachverhalts. Wir denken, das ist dann der akzeptable Weg,
der einerseits wenig internen Overhead und wenig Sperrzeit verursacht,
andererseits in gewiß nur sehr seltenen Fällen ein Nachbearbeiten
von Sätzen notwendig macht. (Wir hatten im update.job gedacht, diese
Fälle noch reduzieren zu können, aber solches Bemühen ist sehr
wahrscheinlich wenig fruchtbar.)

(Übrigens führt acon keine Liste der während des Jobs gesperrten
Sätze, um diese am Ende wieder freizugeben, falls noch nicht
geschehen.)

Zu überlegen ist auch noch, ob die nicht gespeicherten Sätze besser
in einer eigenen Datei gespeichert werden sollten, und zwar im
Externformat, damit man diese Datei dann evtl. unmittelbar für
das weitere Procedere der Nachbearbeitung heranziehen kann, etwa
zum Kopieren der Sätze direkt nach a99 oder so.

Für die so spezifizierte Arbeitsweise müssen wir noch ein paar
kleinere Punkte in der Klassenbibliothek umd im acon-Quellcode
erledigen, bevor wir die neue Update-Lösung bereitstellen können.

B.Eversberg