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

[Thomas Berger]

Lieber Herr Eversberg,


>> 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".
>>
> Sollen wir also den Befehl "lock rec" ganz aus dem Programm nehmen?

Die Versuchung liegt nahe, weil eine Datenbank, die mit einem
einzigen Lock (dem TBL-Lock) auskommt, immun gegen Deadlocks ist
und nach meinem Eindruck eine Datensatzsperre derzeit nirgendwo
wirklich genutzt wird.

Andererseits gibt es noch Anwendungen, die PRESTO einsetzen.

Mein Eindruck ist auch, dass ORDER und ALF davon profitieren
koennten, mittels Datensatz-Locking etwas aehnliches wie
"Transaktionen" beim Buchen oder Berechnen zu erreichen.



>>>> 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?
>>
> Ich meinte, wir können *aus der Betrachtung* ausschließen, daß
> so etwas einen Einfluß auf die Speicherlogik haben könnte. Und nicht,
> *daß* so etwas veranstaltet wird.

Aenderungen am Index haben Einfluss auf die Berechnung der "alten"
Schluessel. Definitiv. Warum haetten Sie sonst die Pseudoschluessel
eingefuehrt, um das etwas abzuglaetten?



>> Wie war denn das Verhalten des alten UPDATE.EXE an der Stelle?
> Nicht besser, aber da muß ich mal nachschauen, ob ich eine
> zusammenfassende und ohne viel Kenntnis verständliche Übersicht
> finde oder leicht zusammenstellen kann.

Es ging mir eigentlich darum, dass man im update.job konkret
dieses Verhalten nachbildet, auch wenn besseres denkbar waere.


> Was wir ja sind, und weswegen das Nachschauen bei der nun
> anvisierten Arbeitsweise nicht mehr entscheidet, sondern alles füt die
> Datenkonsistenz entschdeidende spielt sich innerhalb der put-Logik ab.

Guter Ansatz.

"Alles" aber erst dann, wenn auch das Berechnen der "Alt"-Schluessel
dort hineingezogen wird (innerhalb der Gesamtsperre der Datenbank).
Bzw. "Alles ist relativ" ;-)



> Verbesserungen (Verlängerungen) der Zeitstempel als Identitätsmerkmal
> und allein entscheidenden Werkzeugs zum Erkenntnisgewinn
> sind durchaus leicht machbar, wie ich bei näherer Betrachtung
> feststelle, aber es muß so geschehen, daß wir
> a) nicht ein Umformatieren aller Datenbanken erzwingen, also
> b) die Länge optional machen, d.h. dem Anwender anheimstellen.
> D.h., es kommt nur eine optionale Verlängerung der #99e in Frage.
> 
>>> 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
> Nur zur Laufzeit im Arbeitsspeicher, nicht in einer Datei!

Aber nichts anderes meinte ich doch die ganze Zeit!

Wenn ich mit den Mitteln der Job-Sprache Kryptographie betreiben will,
muss ich mir auch geeignete Datenfelder definieren, darum geht es aber
nicht.

Gemeint ist das banale Cachen ("Einlesen") von Datensaetzen in den
Arbeitsspeicher von acon und a99 nebst Mechanismen, die bei der
Entscheidung helfen, ob so ein gecacheter Datensatz noch valide ist.



> Nein, dieses Risiko geht man derzeit ein. Wie gesagt, wenn man sich dann
> zum Anhängen von X Byte an #99e entschlösse, säh's schon besser aus,
> wenngleich auch dann ein Restrisiko immer bliebe - oder wo ist Ihre
> Schmerzgrenze der Wahrscheinlichkeit? (Denn eine solche bleibt es
> letzten Endes ja immer)

Ganz unabhaengig von den obigen Ueberlegungen kann man ueber das
Format der Zeitstempel einmal nachdenken:

* Aktuelle Betriebssysteme stellen die Systemzeit durchaus mit
  Milli- oder Mikrosekunden-Genauigkeit bereit, das "mitzunehmen"
  duerfte technisch keine besondere Schwierigkeit sein

* PICA-Iltis habe ich in unguter Erinnerung, weil (zumindest in
  MAB-Exporten der DNB) der Ersterfassungs-Stempel zunaechst
  MAB-ueblich auf Zehntelsekunden genau exportiert wird, nach
  der ersten Bearbeitung jedoch wird das "Datum der letzten Aenderung"
  in dieser Aufloesung exportiert, das Ersterfassungsdatum jedoch
  nur noch Tagesgenau. Gewisse Fehlersuchen (wurde ein Satz komplett
  umgeschrieben, gab es eine Manipulation an der Identnummer eines
  anderen Satzes, gibt es ein Problem = Identnummernkonflikt in
  der Datenbank) werden dann stellenweise unmoeglich.
  Will sagen: Man sollte stets moeglichst feinkoernige Zeitstempel
  nutzen und ich kenne keinen Grund, die zu verkuerzen

* Bei einem Projekt, bei dem zwei Datenbanken in verschiedenen Zeitzonen
  miteinander gekoppelt wurden, mussten die Zeitstempel waehrend der
  Uebertragung jeweils umgerechnet werden, damit nicht neuere
  Fremdsaetze als aelter als lokale Saetze erschienen oder
  umgekehrt (waere die Umrechnung nicht erfolgt, waeren solche Datensaetze
  je nach Konstellation und Richtung nie oder zu zwei Zeitpunkten
  selektiert worden, fuer kontinuierlichen Bidirektionalen Datenaustausch
  war das ncht akzeptabel).
* Fuer OAI (und alles, was mit "Internet" zu tun hat) sind korrekte
  Umrechnungen auf GMT noetig (bzw. korrekte Zeitzonenangaben inkl.
  Sommer/Winterzeit).
=>Entweder Zeitstempel in GMT hinterlegen oder mit Angabe des (vom
  Betriebsystem erfragbaren) Zeitzonenoffsets ("+0100" etwa)


* Die mit Unterfeld-Dreieck angeklebten Bearbeiterkennungen sind gegen
  die Syntax von Unterfeldern (es fehlt die Unterfeldkennung)

viele Gruesse
Thomas Berger