[Allegro] acon: Locking

[Bernhard Eversberg]

Am 28.05.2011 01:20, schrieb Thomas Berger:
> 1.
> 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.

> 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
doch mal dazwischenkäme, ist ja doch die Wahrscheinlichkeit
einer Interferenz äußerst gering. Gewiß, sie sollte Null sein,
aber momentan ist das Utopie.

 > Ich persoenlich koennte sowohl mit permanenten
 > Datensatzsperren im Stile von PRESTO oder a99 leben als mit
 > kurzfristigen, die nach Ende des aktuellen Flexes oder Jobs
 > automatisch aufgehoben werden.
Daa zweite wäre auch schwierig, weil ja im Verlauf eines
Jobs mehrere bis viele Sätze bearbeitend angefaßt werden
können. Mit dem ersteren sagen Sie aber doch, daß Sie mit
der "puren Schikane" des "set lock" durchaus leben können.

> 3.
> Absolut gravierend ist, dass beim aktuellen acon ein "set lock" auch
> bei gesperrtem Datensatz nach ca. 15 Sekunden zurueckkehrt, ohne dass
> das Scheitern mittels "if no", "if not ok", "if error" oder dergleichen
> erkannt werden kann: Der Satz ist zwar hinterher gesperrt, aber man
> weiss nicht, ob von einem selbst (gut) oder von anderen (fatal).
>
Hm, da sollte sich was machen lassen. Wir prüfen zuerst die
Stichhaltig-, dann die Machbarkeit.

B.E.