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

[Bernhard Eversberg]

Am 17.01.2012 13:57, schrieb Thomas Berger:
>
> aber wie kommt er denn vorher auf die Platte, damit ich ihn vor dem
> Speicherbefehl betrachten kann? Dieser Zaehler muss also von dem
> (durchaus) fremden Prozess, der den Satz zuletzt gespeichert hat,
> in den Datensatz hineingeschrieben worden sein, vermutlich schwebt
> Ihnen da ein "als Anhaengsel an die #99e" vor.
>
Ja natürlich! Das jetzige Datum, das ja der Prozess da reinschreibt,
ergänzt er eben durch Nummer etc. oder sonstwas.

> Da gibt es dann ein gewisses Risiko, dass zwei Prozesse, die dieselbe
> Update-Datei verarbeiten (aus welchen Gruenden auch immer), zufaellig
> so absolut synchron sind, dass selbst dieser Job-interne Bearbeitungs-
> zaehler nicht greift
... und noch derselbe Operator!
Jetzt spintisieren Sie aber! Das ist ein irreales Szenario.
Und wenn's dieselbe Update-Datei ist, dann ist es doch eh egal! Oder es
ist ein Unfug, der gar nicht stattfinden sollte, und sowas könnten wir
mit keinem Mittel vereiteln.

> (anderes denkbares Beispiel: Die erste Aktion in
> einer a99-Sitzung in einer hypothetischen Bibliothek ist immer das
> Wegschreiben eines Protokoll-Eintrags in einem bestimmten Datenstatz).
>
Und ausgerechnet der soll in einem Update vorkommen, das zeitgleich vom
selben Bearbeiter vorgenommen wird? Nur dann würd's doch kritisch.
Nein, ich glaube, wir können uns ausdenken was wir wollen ...

> Ich habe daher darauf hingewiesen, dass ein globaler Bearbeitungszaehler
> fast ebenso einfach zu implementieren waere und eine 100%-Loesung
> darstellt. Eine dritte Moeglichkeit ist ein datensatzspezifischer
> Versionszaehler, wo dann bei jeder Bearbeitung "eins drauf" gesetzt wird.
>
Das ist endlich mal ein nicht so hammerartiger Vorschlag
(Vorschlaghammer) wie die checksum.
Aber aufwandsmäßig fahren wir günstiger mit dem oben diskutierten 
Modell. Nur evtl. eben der Versionszähler statt sitzungsinterne Zähler,
mal schauen.


B.E.