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

[Bernhard Eversberg]

Am 16.01.2012 13:37, schrieb Thomas Berger:
>
> 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 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.

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

>
> 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.
Ja ok, aber in diesem Zuammenhang besonders wichtig ist das ja
gar nicht.

>
> 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.
>
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.
Das Nachschauen, ob gesperrt, soll nur dazu dienen, solche Sätze dann,
anstatt endlos auf Rückkehr aus dem "put" warten zu müssen, gleich
nach einer relativ kurzen, vo mir aus konfigurierbaren Wartezeit
ausgesteuert werden können.

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!

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

>>>
>>> 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.
>
Hätte aber nichts mit dem momentan verhandelten Thema zu tun.

B.E.