[Allegro] Test wegen der Satzsperrungs-Problematik

[Bernhard Eversberg]

Datensicherheit, um das klar zu sagen, ist uns von hoher Wichtigkeit,
unsere Anwender sollen sich nicht sorgen müssen um mögliche Schäden,
die im ganz normalen Betrieb auftreten könnten. Die Diskussion der
letzten Tage könnte den Normalanwender - falls er sie verfolgt hat -
verunsichern. Das ist uns nicht egal.
Um Bergers Bedenken nicht rundweg abzubügeln ohne substantielle
Empirik, und um nicht den Eindruck von Wurschtigkeit angesichts von
wenn auch seltenen, so doch denkbaren Datenschäden oder Inkonsistenzen
zu erwecken, haben wir einen Extremtest gemacht.

1. Ein Satz mit mehr als 8k Größe wurde angelegt.

2. Ein acon-Job wurde gestartet, der diesen Satz pausenlos 400mal
    einlas, jeweils am Anfang und Ende ein Feld mit einer laufenden
    Nummer einfügte und ihn wieder speicherte.

3. Er wurde dabei nicht länger, kam also immer an dieselbe Stelle.

4. Parallel wurde ein a99-FLEX gestartet, der denselben Satz 400mal
    pausenlos einlas und exportierte mit e-1.apr.

Dies wurde auf einem Einzelplatz mit Win'7/32 ausgeführt und auch
auf einem stark beschäftigten Win-2008-Server.

In beiden Tests ergaben sich 1 bis 3 Fälle, wo beim Export der Satz
am Ende eine andere Nummer hatte als am Anfang. Das waren also
eindeutig Fälle, wo acon mit dem Schreiben genau in die Leseaktion
von a99 hineinfunkte: a99 las den Satz, und bei diesem Lesen gab es eine
Unterbrechung - die a99 nicht bemerken konnte - währenddem acon
drankam und den Satz nach Änderung neu wegschrieb, auf dieselbe Stelle.
a99 las danach weiter, und am Ende des Satzes stand dann natürlich eine
andere Nummer als am Anfang, die nächste nämlich. (Das wäre u.U. nicht
passiert, hätte nicht auch noch Bedingung 3. gegolten!)

Das Wichtigste:
Datenfehler in der Datenbank, wohlgemerkt, gab es KEINE! Die Speicherung
des Satzes war stets konsistent, Indexeinträge und Satzadressen 100%
in Ordnung. NUR der zu gleicher Zeit produzierte Export-Output war
problematisch.

So etwas würde manch einer vielleicht dennoch gerne verhindert wissen.
Ein Export soll schließlich konsistente, zuverlässige Daten liefern.
Wer wollte das bestreiten?
Aber hat das Beschriebene etwas mit realen Situationen gemein?
Man muß sich zwei Fragen stellen:

A. Würde man überhaupt zu Zeiten, wo ein Update läuft, der just an
    den zu exportierenden Daten Änderungen machen könnte, einen Export
    veranstalten, der zuverlässige, konsistente Daten liefern soll?
    Es geht ja nicht nur um das Problem von Sätzen, die in sich nicht
    konsistent sind, wie in diesem Test! Sondern auch generell um die
    Frage, ob bestimmte Sätze während des Exports zufällig geändert
    werden durch den Update, und hätte man den Export etwas früher
    oder etwas später gemacht, dann würden sich die Ergebnisse
    sowieso unterscheiden, und zwar völlig unvermeidlich!

    Anders gesagt: Exporte, die einen bestimmten Datenstand zuverlässig
    dokumentieren sollen, macht man nicht, während just die betroffenen
    Daten aktualisiert werden, manuell oder mechanisch. Denn einige Sätze
    werden dann zwangsläufig aktueller sein als andere, ganz unabhängig
    vom Berger-Extremproblem.

B. Im Test war die Wahrscheinlichkeit relativ hoch, daß der zu
    exportierende Satz - das war ja immer derselbe! - just im selben
    Moment des Lesens durch a99 durch acon weggeschrieben wurde, und
    a99 beim Lesen durch acon unterbrochen wurde. Aber ist ein Lesen und
    gleichzeitiges Updaten desselben Satzes hunderte von Malen
    hintereinander denn wohl realistisch? Wenn sogar hierbei weniger als
    1% Fälle der in Rede stehenden Art passieren, dann werden solche
    Output-Fehler in realen Situationen noch ganz erheblich seltener zu
    erwarten sein. (Mal abgesehen davon, daß man die Gefahr, siehe A.,
    sowieso organisatorisch unterbinden würde!)

Und zum dritten war es so, daß der besagte Satz größer war als 8k, und
die zu beobachtende Differenz durch das Unterbrechungsphänomen trat
stets im zweiten Teil auf, hinter der 4k-Grenze. Sätze dieser Größe
sind in realen Situationen selten, d.h. die geringe Wahrscheinlichkeit
wird durch die Blockgröße des Betriebssystems nochmals stark reduziert:
es werden augenscheinlich immer mindestens 4k ohne Unterbrechung
gelesen.

Gleichwohl, wer 100% will, auch in den durch Frage A gekennzeichneten
Situationen, der kann immer noch den eingelesenen Satz beim Export
zuerst sperren, dann nochmals einlesen, exportieren, und wieder
freigeben. Das wurde auch getestet, dabei ging natürlich der Export
etwas langsamer, aber es kam kein Fehler raus. Wir stellen also
anheim, es so zu machen, werden es aber aus den genannten Gründen
nicht allgemein so einrichten, daß ein eingelesener Satz grundsätzlich
erst mal automatisch gesperrt wird - denn wann sollte er wohl wieder
automatisch und zuverlässig freigegeben werden? Und die von Berger
angedachte Methodik des inkrementellen Einlesens mit domain locking,
nun ja, die kann er sich selber implementieren, wir halten das nach
diesen Feststellungen aber für unverhältnismäßig, zumal die in A.
angesprochene Problematik auch dadurch nicht gelöst würde.


B.E.