Satzsperren etc.

[Thomas 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 :-(


> C --------------------------------------------------------
> Nutzer:
> - geaenderten Satz speichern
> System:
> 1 - alle beteiligten Dateien lock (atomar: .xDX, .TBL, .xLD, evtl
>     ..STL)
>            NUR .TBL wird gesperrt, die anderen sind dadurch bereits
>            gleichfalls geschuetzt, da ja niemand anders dann
>            ueberhaupt schreiben kann

etwas genauer, damit nicht Babylon einzieht:

1a .TBL Lock (atomar, falls gescheitert neuversuch 1a)
1b .TBL sperren (falls nicht gesperrt, sonst .TBL unlock, neuversuch 1a
)
1c .TBL unlock (atomar, falls gescheitert
Betriebssystem-Sicherheitsloch)

Durch diese "Molekuelbildung", also das Einkapseln in atomare
Operationen, wird das nicht-atomare ~Sperren der Satztabelle~
zu einer quasi-atomaren Operation (gibt bestimmt auch ein
Fachwort dafuer) und damit sicher. Falls das Netzwerkbetriebssystem
mit den atomaren Operationen des Lockings aber Probleme hat, 
ist es nicht absolut sicher und man hat nur die heuristische 
Sicherheit durch das Sperren der .TBL.


> wenn erfolgreich:
> 2 - aktuellen Zustand der zu veraendernden Dateien neu einlesen: .xDX,
>     .xLD .TBL, .STL
>   a99/alcarta: wenn Datum in #99e nicht mehr identisch: Kein Speichern
> 3 - beteiligte Dateien aktualisieren
> 4 - alle beteiligten Dateien unlock (atomar)
>     nur TBL wird freigegeben, die anderen waren ja nicht gesperrt
>     Der Satz wird durch das eigentliche Schreiben schon wieder
>     entsperrt (das erste wird wieder 1)

genauer:
4a .TBL Lock (atomar, falls gescheitert neuversuch 4a)
4b .TBL freigeben (falls bereits freigegeben: Allegro-Sicherheitsloch
oder
      unzulaessige Intervention des Allegro-Administrators)
4c .TBL unlock (atomar, falls gescheitert
Betriebssystem-Sicherheitsloch)

D.h. also, das ~Sperren~ der .TBL *kanalisiert* den exklusiven
Zugriff auf alle zu beschreibenden Dateien. Anders ginge es auch 
nicht, denn sonst gaebe es die Moeglichkeit des beruechtigten 
Deadlocks:
Ein PRESTO haette dann .TBL und .STL blockiert und wartet auf
die Moeglichkeit, sich .ADX und .LOG zu krallen, ein anderes 
hat genau die beiden anderen und beide koennen nicht vorwaerts...


viele Gruesse
Thomas Berger