[Allegro] acon: Locking

[Thomas Berger]

Lieber Herr Eversberg,

>> gibt man bei acon put, und die .TBL-Datei ist gesperrt, so kehrt das
>> Kommando nach kurzer Zeit mit Error zurueck, der CString Err ist belegt
>> mit "TBL gesperrt - Speichern gelang nicht".
>> Das ist soweit in Ordnung, aber liesse sich nicht ein numerischer
>> Fehlercode zurueckliefern (so wie fuer Err dokumentiert)?
>>
> Das haben Sie in der Hand: Zeile 175 in uifsger ändern.

Und das aendert es dann in allen existierenden Installationen
direkte mit? Eine wahrlich globale Aenderung.

Es ist doch so: Wenn ich eine Meldung bezueglich Schreibfehlern
bekomme, waere es zwecklos, noch einmal speichern zu wollen.
Bekomme ich hingegen eine Meldung bezueglich irgendwelcher Sperren,
sollte ich hingegen alles (nach angemessener Pause) noch einmal
versuchen. Auf einen Text zu pruefen klappt (so lange niemand diese
in seiner uifsger verschoent hat), aber der CString Err ist
dokumentiert als

avanti: Interne Nummer des letzten Fehlers

und daraus schliesse ich, dass jeder Zustand eine interne Fehler-
nummer hat auch unabhaengig von Setzungen in uifsger.



>> 2.
>> Die Forderung, vor einem "put" ein "set lock" zu setzen, ist m.E. pure
>> Schikane: Der einzige Zeitpunkt, wo der alte Zustand des Satzes eingelesen
>> werden kann und seine Schluessel berechnet werden, ist der Moment des
>> Abspeicherns, wo also bereits die Satztabelle gesperrt ist und
>> Schreibvorgaenge durch andere Prozesse ausgeschlossen sind: Wird der
>> Satz frueher eingelesen (etwa in dem Moment, wo er mit set lock
>> geschuetzt wird), kann es danach immer noch passieren, dass andere
>> Saetze bzw. deren Schluessel sich aendern, die Schluessel des
>> aktuellen Satzes duerfen also noch gar nicht berechnet werden, weil
>> das Ergebnis nicht zuverlaessig ist.
>>
> Nun, man kann ja zusätzlich, um ganz ganz sicher zu gehen,
> set tbl lock
> noch VOR  set lock  schalten, und direkt vor dem "put" wieder
> set tbl free
> Das wäre eine ziemlich gute Abhilfe, weil es Schreibvorgänge
> anderer Prozesse kaum mehr zuließe, und selbst wenn ein solcher

ich lese "kaum"...


> doch mal dazwischenkäme, ist ja doch die Wahrscheinlichkeit
> einer Interferenz äußerst gering. Gewiß, sie sollte Null sein,
> aber momentan ist das Utopie.

Mein Problem ist folgendes:
Anscheinend hat "set lock" einen undokumentierten Seiteneffekt,
naemlich den aktuellen Zustand des Satzes in einen internen
Parallelspeicher zu hieven. Verzichtet man darauf, hat ein
folgendes "put" schlimme Konsequenzen, indem naemlich alte
Schluessel nicht (bzw. nicht zuverlaessig) ausgetragen werden,
(z.B. auch der Primaerschluessel, und gibt es spaeter ein Erase
bleiben Schluessel zurueck, die auf geloeschte bzw. mit anderen
Inhalten nachgenutzte Saetze zeigen)

D.h. um auf Nummer sicher zu gehen muss man stets unterbrechungslos

set lock;put

schreiben (und wohl auch: "set lock;erase").

Ich finde den Rekurs auf "acon ist kein interaktives Programm und
daher muss man es so machen" nicht schluessig und mir faellt auch
sonst keine Begruendung ein: Wie ich oben dargelegt habe, muss
dieser hypothetische Zwischenspeicher unmittelbar im Zusammenhang
mit "put" aus der Datenbank beschickt werden und mit einer
Datensatzsperre hat das ueberhaupt nichts zu tun: Darauf kann
vorher getestet werden oder man laesst es darauf ankommen, dass
das put evtl. scheitert und versucht es anschliessend noch einmal,
auf die Korrektheit des anschliessenden Speicherns kann das keinen
Einfluss haben.

So wie Sie es schildern muss man also statt put wie folgt schreiben

set tbl lock
set lock
put unlock

(nur dass "put unlock" angeblich(?) fuer acon gar nicht implementiert
ist)


viele Gruesse
Thomas Berger