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

[Bernhard Eversberg]

Am 16.01.2012 12:18, schrieb Thomas Berger:
>
> Nein, ich meine nicht den Anwender, sondern den Job-Programmierer:
> Sobald mehr als ein Lock in der Anwendung vorkommt, hier also
> Datenbank- plus Datensatz-Lock, kann es zu Deadlocks kommen, und wenn
> es keine Spielregeln gibt (Reihenfolge, Ruecknahme zwecks Konflikt-loesung),
> wird es dazu kommen.
>
Wie gesagt, das .tbl-Lock kommt ja nun raus aus der Job-Prozedur, und im
Job selbst wird nichts mehr gelockt werden, das macht allein "put".
Der Job prüft nur den Satz, ob gesperrt, und macht nur damit weiter,
wenn nicht. Sobald es aber zum "put" kommt, greift dessen interne
Logik, die sich nicht auf das Lock allein verläßt, sondern auch noch
die Zeitstempelprüfung.

>
>>>   und anschliessendem
>>> "set tbl lock" nur im Fall einer zugeschalteten Parameterdatei,
>> Was täte denn diese dabei zur Sache?
>
> Die koennte - wg. eigener Indexzugriffe als Grundlage der
> vorzunehmenden Manipulationen - Wert darauf legen, dass der Index
> sich vor dem Speichern nicht noch einmal aendert (Zaehler,
> Zustand von v14-Ersetzungsschluesseln, ...).
>
So etwas können wir ausschließen.

>
> Die Schluesselermittlung des "vorher"-Zustands ist strenggenommen
> nur unmittelbar im Zusammenhang des Speicherns zulaessig, denn
> zwischen Einlesen des Satzes und Speichern koennte man zwar durch
> eine Datensatzssperre gewaehrleisten, dass sich der Satz nicht
> mehr aendert, die Schluessel (auch die existierenden) haengen
> aber vom Gesamtzustand des Index ab (v14-Ersetzungen, explizit
> in der .api vorgenommene Nachladungen)
>
Interferenzen aus solchen Gründen scheinen mir aber äußerst
unwahrscheinlich bzw., wenn die Datenbank überhaupt mit solchen
Dingen arbeitet, vermeidbar indem man keine konkurrierenden
Updates fährt, und selbst solche sind nicht unbedingt kritisch
noch treten sie regelmäßig auf. Und selbst wenn, dann ergeben sich
keine Datenschäden, und die evtlen Index-Inkonsistenzen verschwinden
bei einer Neuindexierung.

>
>> 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.
>
> Es ist noch nicht einmal entscheidbar, ob man selbst gerade eine
> lange oder viele kurze Sperren beobachtet:
Viele kurze Sperren im Sekundentakt am selben Datensatz?

>
>> 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.
>
> .tbl steht auch stellvertretend fuer exklusiven Schreibzugriff
> auf Index, Tabellen und auch Logdatei.
>
Ja, und darum braucht sich, wie gesagt, der Job nicht zu kümmern,
das passiert in der put-Prozedur.

>
>
> 1. umso wichtiger wird es, die Heuristik vom Zeitstempel zu loesen
> (die Sekunden-Aufloesung ist viel zu grob, und es besteht die
> Gefahr, dass hochfrequente Aenderungen *uebersehen* werden koennen)
> und auf eine kryptographische Pruefsumme umzustellen (irgendein
> Standardverfahren auf die String-Darstellung des Satzes wie eingelesen
> anwenden, und die zugehoerigen 64 oder 128 Bytes irgendwo hinterlegen)
>
Irgendwo?
Das können wir vorläufig nicht realisieren. Im Rahmem von OpenSource
könnte sich ggfls. jemand anders mal darüber hermachen. Es erfordert
Eingriffe, die dann ein Umformatieren aller Datenbanken erzwängen!
Haben Sie schon Fälle beobachtet, die auf die "viel zu grobe" Auflösung
zurückzuführen wären? Kritisch wäre das doch nur, wenn tatsächlich
innerhalb derselben Sekunde, in der ein Satz gespeichert würde, sofort
der nächste Speicherbefehl von jemand anders käme. Sooo schnell sind
aber die zugehörigen Abläufe nun auch wieder nicht, daß beim Vergleich
dann eine Identität des Zeitstempels herauskäme. Übrigens würden statt
64 Bytes dann auch etwa drei an den Zeitstempel angehängte Bytes
vollauf reichen, etwa die des Operatorcodes. Die ohnehin schon da sind,
nur beim Vergleich noch nicht verwandt werden, aber werden könnten.
Ihnen, schon klar, würde auch das nicht genügen, Sie verlangen
eine astronomische Unwahrscheinlichkeit - wenn es denn schon eine
absolute nicht geben kann (wie Sie nachzuweisen nicht müde werden). Wie
gesagt, dann implementieren Sie die 64 oder 128 Bytes, wir kommen da
momentan nicht zu. (Sie müssen die nicht "irgendwo" ablegen, sondern
hinter dem Zeitstempel in #99e, und sie dann in den Vergleich
einbeziehen. Wirklich astronomisch sind aber auch 128 längst noch nicht.)

> 2. Das Update einer groesseren Datei sollte sich nicht von einem
> fluechtigen Phaenomen wie einer fast-simultanen Bearbeitung aus der
> Bahn werfen lassen, jeder "ignorierte" Datensatz bleibt potentiell
> unbemekrt bzw. ist extrem muehsam zu ermitteln und wiedervorzulegen.
Deswegen ja das Protokollieren der nicht speicherfähigen Sätze.

> Zudem wird das Speichern wird auch verweigert, wenn eine (fremde)
> Satzsperre besteht, das abzuwarten koennte sich lohnen.
>
Sicher, wenn man diesen Fall denn erkennen könnte! Geht ja aber
grundsätzlich nicht.

> In update.job sollte daher Ablauflogik implementiert werden,
> die beim Scheitern des "put" (bzw. qualifiziert auf die Gruende
> des Scheiterns reagierend) auf Grundlage des bereits eingelesenen
> Update-Satzes die Schritte ab Primaerschluesselberechnung, Ermittlung
> des Zielsatzes in der Datenbank etc. in einer gewissen Anzahl
> oder Zeitdauer erneut versucht.
>
Skizzieren Sie das mal in einer programmierbaren Ablauflogik.

>
>> (Übrigens führt acon keine Liste der während des Jobs gesperrten
>> Sätze, um diese am Ende wieder freizugeben, falls noch nicht
>> geschehen.)
>
> aber warum hiess es dann, man koenne keine sitzungsuebergreifenden
> Datensatzsperren "mit avanti" realisieren, oder erinnere ich mich
> da ganz falsch?
>
Wo stand das?

>
>
>> Zu überlegen ist auch noch, ob die nicht gespeicherten Sätze besser
>> in einer eigenen Datei gespeichert werden sollten, und zwar im ...

Der Rest ist Konsens.
Insgesamt wird ein Prozedere rauskommen, welches sicherer ist als das
alte update.exe. Sollte Ihnen das nicht reichen, können Sie jenes auch
nicht mehr nutzen! Dabei hatten wir es vor Jahren gemeinsam in langen
Testreihen schließlich so abgedichtet, daß bestimmte Dinge dann nicht
mehr passierten.

B.E.