[Allegro] Frage zu acon und "put"

[Anando Eger]

Liebe Listenleserinnen und -leser,

dem Untenstehenden stimme ich 100%ig zu - schön, dass Herr Berger 
das noch einmal so klar aufgeschrieben hat.

Viele Grüße
Anando Eger


On 9 Jan 2012 at 14:08, Thomas Berger wrote:

> 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
>