[Allegro] Frage zu acon und "put"

[Thomas Berger]

Lieber Herr Eversberg,

>> Die Bemerkung oben bezog sich auf den (zugegeben unterstellenden)
>> Verdacht, dass Sie aus einem negativen Ergebnis von "if lock" auch
>> Schluesse ziehen wollen (etwa der Satz wird nicht ignoriert). Das
>> ist aber hochgradig gefaehrlich, denn sobald Sie nun den naechsten
>> Schritt vornehmen, kann das negative Ergebnis von "if lock" schon
>> laengst obsolet sein
> 
> Und das ist höchstgradig übertrieben, denn der zeitliche Zwischenraum
> zwischen den Aktionen "if Lock" und "set lock" beläuft sich auf
> Millisekundenbruchteile! Ob man hier daher auf Biegen und Brechen einen

Woher wollen Sie das wissen? Das Betriebssytem unterbricht Ihren
Job, der Prozessor hat mehrere Kerne, die Datenbank liegt auf einem
anderen Rechner etc. Und selbst im Einzelplatzbetrieb unter DOS 6.0
kann ein Leeren des Plattencaches viele Sekunden Zwangspause eingeschoben
haben. Das war natuerlich unschaedlich. Diese "Millisekundenbruchteile"
sind ein Null-Argument, es bedeutet ja nur, dass die Rechner sehr schnell
sind, aber alle anderen Akteure haben damit sogar im Zweifelsfall bessere
Chancen, sich dazwischenzufummeln.


> noch höheren Aufwand treiben muß, sei dahingestellt. Mit Kanonen auf

Es ist absolut unumgaenglich, solche Konstruktionen korrekt zu
benutzen. Und zwar auf jeder Ebene: Die Vorgehensweise im acon-Job
benutzt ja das "set lock"-Feature von a99/acon, und das wiederum
nutzt hoffentlich Locking-Features des Betriebssystems (Byterange-Locks
unter Win32, irgendeine noch nicht genau studierte Emulation dessen unter
Linux). Sicherer Betrieb ist nur dann gegeben, wenn auf jeder dieser
Ebenen alles logisch sauber implementiert ist.


> Mücken, das ist unser Stil nicht. Ich weiß jetzt auch gar nicht, ob
> das alte update hier eine granatenfeste Höchstsicherheitstechnologie
> hatte - sind Sie damit schon mal an die Wand gefahren in der Hinsicht?

In Bezug auf die Satztabelle jahrelang, zum Schluss war es allerdings ziemlich
sauber, auch wenn in manchen Installationen immer noch merkwuerdige Dinge
passierten. Kaputte Datensatzsperren haben naturgemaess nicht so ein
Zerstoerungspotential wie Datenbanksperren und Konflikte sind auch rechnerisch
(meist) seltener, aber es darf einfach keine Toleranz gegenueber Daten-
inkonsistenzen geben, zumal bereits einzelne Inkonsistenzen (z.B. in der
Leersatzverwaltung oder bei einmal gebrochenen Datenbank-Locks) den
Effekt haben koennen, dass Folgefehler zwangslaeufig und sehr haeufig
entstehen. D.h. Sie haben jahrelang Glueck und dann fuehrt eine einzige
initiale Inkonsistenz dazu, dass innerhalb von Stunden die erfolgenden
Bearbeitungen die Datenbank regelrecht zersieben.

viele Gruesse
Thomas Berger