Was tun bei Vermischten Datensaetzen?

[Thomas Berger]

B. Eversberg wrote:

> > Aeltere Versionen von NFS unterstuetzen kein File-Locking,
> > aeltere (=alle?) allegro-X-Programme daher wohl auch nicht.
> > Damit ist es dann theoretisch unmoeglich ein Programm zu
> > haben, das im Netzwerkbetrieb korrekt funktioniert.
> 
> Dem hatten wir eigentlich vorgebeugt mit der Methodik, uns nicht auf
> das betriebssystemeigene Locking zu verlassen, sondern mit einem
> direkt in die TBL bzw. in den Datensatz geschriebenen Byte ein Flag
> zu setzen. Nur in Situationen, wo zwei Personen wirklich im Abstand
> von Sekundenbruchteilen speichern, koennte diese Sperre noch
> durchbrochen werden (sog. "race condition"). bei NT und bei Novell
> allerdings nicht, weil da auch noch ein normales File-Locking
> zusaetzlich gemacht wird, etwa seit V15a.

So ist es auch richtig, alle Sicherheitsmechanismen
greifen Hand in Hand:

Makroskopisch:
  - "Signalfile" cat.sgf: Kein Bearbeiter darf mehr
    mit der Bearbeitung der Datenbank beginnen
    (wg anstehender Reorganisation etc.), noch aktive
    Bearbeiter werden mit dem Telefon aus der
    Datenbank herauskomplimentiert (Termin fuer
    automatische Telefonfunktion von a99?)

  - Datensaetze in Bearbeitung sind individuell
    gesperrt. Das schuetzt vor gleichzeitiger
    Bearbeitung durch andere, auch waehrend
    der Mittagspause (obwohl man hier erziehend
    auf die Kollegen einwirken sollte, die
    Bearbeitungszeiten auf ein Minimum zu
    reduzieren).
    Stuerzt der Rechner waehrend der Bearbeitung
    ab (Stromausfall, Fenster zugeklickt, Fenster
    in der Taskleiste verbuddelt, nach Hause gegangen),
    so ist dieser Satz fuer immer gesperrt, und kann
    durch den Administrator bzw. Benutzer, die die
    entsprechende Stelle im Handbuch gelesen haben,
    durch eine spezielle Tastenkombination "entsperrt"
    werden. Vorher ist allerdings zu klaeren, dass
    dieser Satz wirklich nicht mehr in Bearbeitung
    ist, sonst koennen Inkonsistenzen entstehen
    (das ist hoffentlich klar).

Mikroskopisch:
  - Beim Abspeichern eines neuen oder modifizierten
    Datensatzes wird die .TBL-Datei durch allegro
    "gesperrt", damit exklusiver Schreibzugriff
    auf .TBL-, und Indexdatei sowie das *aktuelle*
    Ende der .LOG- und ggfls. der betroffenen 
    .cLD-Datei (umspeichern!) gewaehrleistet ist. 
    Je nach Anzahl der auszutragenden und einzumischenden 
    Schluessel und Langsamkeit des Netzes / Groesse 
    der Datenbank / Anzahl der Leersaetze bei "//"
    muss diese Exklusivitaet fuer einige hundert 
    Millisekunden bis zu mehreren Sekunden aufrecht
    erhalten werden, bis das Speichern halt abgeschlossen
    ist.
    Versuchen andere Arbeitsplaetze waehrend dieser
    Zeit, ebenfalls zu speichern, so erscheint
    unten auf dem Schirm ".TBL-Datei gesperrt",
    und es wird 60 Sekunden lang automatisch
    versucht, ob das Speichern moeglich geworden
    ist. Dies ist ueppig dimensioniert, nur bei
    globalen Ersetzungen, globalen Manipulationen,
    Turbo-Updates etc. kann es dazu kommen, dass
    hier der urspruengliche Arbeitsplatz mit vielen
    Schreiboperationen in unmittelbarer Folge
    die Datenbank fuer andere Bearbeiter "dicht
    macht".
    Stuerzt das urspruengliche PRESTO waehrend
    des Speicherns ab (Stromausfall, Netzwerkaussetzer,
    korrupte Datensetze, pathologisch lange
    Datensaetze, Fehler in der Parametrierung, 
    Bugs in PRESTO, ...), so ist die Satztabelle
    dann "auf ewig" gesperrt. Der Systemverwalter
    muss in diesem Fall die Situation klaeren und
    entscheiden, ob der die Satztabelle manuell
    freigibt: Ueber den entsprechenden Menupunkt
    im Cockpit bzw. mittels Sniffer (aeltere Cockpit-
    Versionen koennen in Microsoft-Netzwerken die .TBL
    nicht freigeben, wenn die Datenbank in Benutzung
    ist, die neueren Cockpit-Versionen sowie alle
    Versionen von SNIFFER koennen es).

"Nanoskopisch":
  - In Mutlti-Tasking Umgebungen (Windows, jedes
    Netzwerk) sind die Zustaends*uebergaenge* bei
    den oben genannten Schutzmechanismen kritisch.
    Es ist beweisbar, dass hier 100%ige Sicherheit
    nur dann gegeben ist, wenn das zugrundeliegende
    Betriebssystem hier Mechanismen bereitstellt.
    Am verbreitetsten und dem Problem hier auch
    am angemessensten ist das File oder Record
    locking, das hier etwa gewaehrleistet, dass
    es nie zwei PRESTOs gleichzeitig die Satztabelle
    fuer sich sperren. Wegen der langen Dauer der
    Schreiboperationen waere es kein guter Stil,
    das Sperren der Satztabelle oder gar das der
    einzelnen Datensaetze ueber das Betriebssystem-
    Locking zu realisieren:  Das Betriebssystem 
    stellt nur die sogenannten atomaren Operationen
    zur Verfuegung, die allegro (und alle Anwendungen,
    die auf gemeinsame Dateien zugreifen) fuer den
    Aufbau eigener Sicherheitsmechanismen unbedingt
    benoetigt.

a99 uebrigens benutzt, da hier ja tendenziell 
hunderte von Saetzen gleichzeitig bearbeitet werden
und Sitzungen "aufbewahrt" werden koennen, auf der
makroskopischen Ebene nicht das Sperren von Datensaetzen,
sondern den Vergleich der Aenderungsdaten als
Anhaltspunkt dafuer, dass keine Gleichzeitige
Bearbeitung eines Satzes stattgefunden hat. Dies
ist eine Heuristik und einige Sachen sollten
beherzigt werden:
- Man sollte bearbeitete Saetze moeglichst sofort
  abspeichern (sonst sieht man die Bearbeitungen
  ja auch nicht im Index)
- Man sollte bearbeitete und nicht gespeicherte
  Saetze nach Moeglichkeit nicht ueber die aktuelle
  Sitzung hinaus aufbewahren
- Man sollte die Datenbank moeglichst nicht
  reorganisieren oder entlueften, wenn irgendein
  Bearbeiter noch nichtgespeicherte, bearbeitete
  Saetze hortet.

Derzeit ist vermutlich noch niemandem (hoechstens
Frau Tews?) klar, wie man als Datenbankadministrator
hier steuernd und organistatorisch eingreifen kann.
Gerade beim Neueinstieg auf a99 stelle ich mir
aber vor, dass es auch fuer die Bearbeiter angenehmer
ist, in der .ini-Datei fuer a99 die Einstellungen
so zu setzen, dass das "Elefantengedaechtnis" von
a99 etwas zurueckgedraengt wird und ein Neustart
von a99 auch moeglichst eine "frische" Sitzung
praesentiert.

viele Gruesse
Thomas Berger