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

[Thomas Berger]

Lieber Herr Eversberg,

>> 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.

Die Zugriffe sind in "put" gekapselt, aber solange der Anwender
ueber die Flex-Sprache die Moeglichkeit hat, diese Locking-Objekte zu
nutzen, ist die Semantik keine innere Angelegenheit von "allegro".


>>>>   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.

Wie kommt die Entwicklungsabteilung auf die Idee, Aussagen zu meiner
Anwendung zu machen?



>> 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.

Wie war denn das Verhalten des alten UPDATE.EXE an der Stelle?

(ich stimme Ihnen ansonsten insofern zu, dass jemand, der
fuer eine Spezialanwendung oder hochgradig unkoordiniert parallele
Updates schaerfere Kontrolle der Lade- und Speichersitutation benoetigt,
dafuer eigene Abwandlungen des Update.job einsetzen sollte).


>>> 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?

Mehrere mittellange Sperren, die nur fuer Millisekunden durch
eine Freigabe unterbrochen sind? PRESTO-Bearbeiter sind
ja noch nicht aus der Welt... Und zu "viele kurze": Im
Zusammenhang mit Ausleihe und Erwerbung gibt es System- und
"Konto"-Saetze, die im Vergleich zu normalen bibliographischen
oder Normsaetzen eine extrem atypische Nutzung haben.

Aber es geht wie immer nicht darum, dass ich Ihnen die nackte oder
sogar moralisch rechtfertigte Existenz solcher Szenarien nachweisen
muss, sondern nur darum, dass "Lock nachgucken" als Werkzeug
des Erkenntnisgewinns Einschraenkungen unterliegt, ueber die man
sich genau im Klaren sein muss.


>> 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!

Nanu, neulich schrieben Sie, dass der gelesene Aenderungsstempel
separat, quasi in "Metadaten" zum Datensatz hinterlegt wird (es
ging ja darum, dass der auch im Satz veraendert werden kann, bevor
es zum zurueckspeichern kommt). Oder bezog sich das auf eine in
acon hinterlegte interne Kopie des "Originalsatzes beim Einlesen"?

Eine Signatur im Datensatz selber wuerde man nur benoetigen, wenn
man den *signieren* wollte (als Schutz gegen Kollegen, die in
ihrer Fruehstueckspause mit dem Hex-Editor ihr Ausleihkonto
manipulieren wollen oder so)


> 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

Ein Update von 60.000 Saetzen pro Stunde schreibt generiert
permanent ca. 15 ununterscheidbare Zeitstempel. Jetzt kann
man mit den Unzulaenglichkeiten von allegro argumentieren, dass
die Performance in Situationen, wo Concurrency auftreten kann,
massiv einbricht. Festzuhalten bleibt aber, dass "15 Bearbeitungen
pro Sekunde" kombiniert mit "kein Locking auf Datensatzebene"
genug Luft fuer folgende Sequenz laesst:

Prozess A schreibt Satz X weg
Prozess A liest Satz X
   Prozess B liest Satz X
Prozess A schreibt Satz X erneut weg
*  Prozess B schreibt Satz X

Bei "*" kann dann die derzeitige Heuristik den Bearbeitungskonflikt
nicht erkennen.


>>> (Ü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?

Ich mache mich mal auf die Suche.

viele Gruesse
Thomas Berger