Netzaufbau

[Anando Eger]

Hallo Herr Fischer,
Sie fragten auf meine Aussage hin

> >UNIX/LINUX-Systeme sind als Dateiserver für allegro/a99 nicht geeignet,
> >als Basissystem für AVANTI dagegen sehr gut.
>
> Koennen sie uns bitte noch etwas zu diesem Thema wissen lassen, da diese
> Konfiguration aus Kostengruenden von etlichen Admins durchaus angestrebt /
> realisiert wird.

Ja, das ist für mich als LINUX-Fan auch sehr betrüblich. Ich war zuerst auch davon
ausgegangen, dass das SAMBA-System, das ja recht erfolgreich einen WinNT-PC
nachbildet, auch für allegro-Dateien geeignet sein müsste. Nachdem ich in der
Praxis mit einer derartigen Netzwerkinstallation Schiffbruch erlitten und sehr viel
Zeit (fehl-)investiert hatte, habe ich mich mit dem Dateizugriffs- und Locking-Mechanismen
unter Allegro beschäftigt. Ergebnis: Ich verstehe nicht, wie das Datei-Locking unter
DOS/Win-Umgebungen überhaupt funktionieren kann, Fehler in der Praxis ließen sich
jedoch durch mich nie reproduzieren - unter LINUX/SAMBA als auch mit echtem
NFS-Clienten dagegen ja. Ich denke, dass die zeitlichen Abläufe im DOS oder Windows
zufällig günstig ausfallen.

Das Thema wurde in der Liste ja unter dem Betreff "Vermischte Datensätzte" schon
einmal andiskutiert.

Praktische Auswirkung: Wenn Sie ein Allegro-Dateisystem auf einem LINUX-Server
installieren und von mehreren DOS/Win-Clienten gleichzeitig zugreifen (Daten einmischen,
editieren, Ausleihen/Rückbuchen) entsteht signifikant häufig Datenmüll. Konkret waren
das in einer öffentlichen Bibliothek mit Ausleihe ca. 10 defekte (vermischte)  Datensätze bei
ca. 500 ... 1000 Buchungen/Rückbuchungen pro Tag, wobei gleichzeitig von anderen PC's
aus Daten erfasst wurden.

Zitate aus alten Mails:
---------- Herr 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

----------- Ende Zitat  --------------------------------------------------------------

Ich hatte dann eine Vermutung über das verwendete Locking-Verfahren
geäußert, die von Herrn Eversberg korrigiert und dann von Herrn Berger
meiner Meinung nach recht treffend kommentiert wurde:

---------- Zitat Herr Berger: ------------------------------------------------------

Lieber Herr Eger, lieber Herr Eversberg,

Zu Herrn Eversbergs Anmerkungen noch einige von mir.

> Die Vermutungen von Herrn Eger sind nicht ganz zutreffend.
> Ich habe angemerkt, wo es nicht stimmt:
>
> A -------------------------------------------------------
> Nutzer:
> - Satz zum Editieren oeffnen  (z.B. presto "E")
> System:
> - .TBL lock          NEIN
> - neu einlesen
> - wenn Satz frei, Sperrkennzeichen setzen
>   sonst Meldung: Satz gesperrt
> - .TBL unlock        NEIN
>
>   Hier waere das Locking ueberfluessig. Es wird ja keine kritische
>   Schreibaktion durchgefuehrt. Die Satzsperre wird von a99 und
>   avanti nicht gesetzt, nur von den DOS-Programmen

Das Sperren eines Satzes ist eine ueberaus kritische
Schreiboperation. Die Wahrscheinlichkeit, dass zwei
Personen denselben Datensatz in etwa gleichzeitig
bearbeiten wollen, ist natuerlich gering, so dass
die Wahrscheinlichkeit von "kritisch gleichzeitig"
evtl. wirklich zu vernachlaessigen ist. (Dies hier
nicht zu verwechseln mit dem Szenario "irgendjemand
schreibt irgendwo", was ja durchaus haeufiger ist).
Also: Locking ist mitnichten ueberfluessig, man
kann aber vermutlich verantworten, dass es nicht
stattfindet.

JEDOCH: Denkt man an Bestellnummerngeneratoren etc.
von ORDER, so sieht man, dass es in einzelnen
Anwendungen durchaus Datensaetze geben kann, die
staendig aktualisiert werden, hier muss also
(hoffentlich bereits in ORDER eingebaut) mehr
Sorgfalt walten. Typisch hier ist aber, dass
der Satz sofort nach dem Lesen automatisch
modifziert und weggeschrieben wird, evtl. ist
hier die Satzsperre ueberfluessig, weil es aus
allegro-Sicht ein "aufgebesserter" Schreibvorgang
ist. (Das ist nicht in ORDER eingebaut, das weiss
ich: es gibt haeufig Aerger mit gesperrten
Bestellnummerngeneratorsaetzen :-(
...
-------------- Ende Zitat --------------------------------------------

Ich habe als Programmierer von Echtzeitsystemen früh gelernt:
jeder Fall ist zu berücksichtigen, auch der unwarscheinlichste.

Wir haben es bei den heutigen, hochkomplexen Systemen
immer mit Warscheinlichkeiten von Ereignissen zu tun, die sich mit der
Weiterentwicklung der Soft- und Hardware in ihrem zahlenmäßigen
Wert auch schnell mal drastisch ändern können....

Also: "unwarscheinlich" oder "kommt nur äußerst selten vor" heißt:
ES KOMMT VOR!!!!

Abschließend: Wenn ich die Meinung vertrete, dass ein Linux/UNIX-Server
nicht für Allegro geeignet ist, meine ich damit konkret, daß unter diesem
System DIE FEHLERHÄUFIGKEIT einer Allegro-Anwendung derzeit
für die Praxis ZU GROSS ist.

Mir liegt das Thema am Herzen, weil ich quasi jeden Tag um die Stabilität
von Allegro kämpfe - deshalb die ausführliche Antwort.

Viele Grüße
Anando Eger

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : anando.vcf
Dateityp    : text/x-vcard
Dateigröße  : 296 bytes
Beschreibung: Visitenkarte f?r Anando Eger
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20010216/0e107777/attachment.vcf>