[Allegro] acon: Locking

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

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


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.

[Die bei "put new" angegebenen Hinweise
>>>
Achtung bei avanti: Stets VOR einer Änderung eines Satzes, der dann wieder
gespeichert werden soll, den Befehl  set lock  geben. Sonst würden die nicht
mehr gültigen Indexeinträge nicht beseitigt. Die Gründe liegen darin, daß a99
ein interaktives Programm ist, acon aber ein Konsolprogramm; das soll an dieser
Stelle nicht vertieft werden.
<<<
kann ich nicht nachvollziehen, vielleicht koennen Sie die Ueberlegungen
dahinter bei Gelegenheit vertiefen]

Die Dokumentation zu "set lock" und "put unlock" scheint mir nicht
konsistent: So wie ich es in Erinnerung habe, merkt sich zumindest acon,
ob *es selbst* den fraglichen Satz gesperrt hat, in diesem Fall
ist dann ein einfaches "put" moeglich und der Satz ist automatisch
freigegeben. (Die Frage waere, ob jemand ein "put lock" benoetigt,
nach dem der Satz immer noch gesperrt waere). Man kann das bei
"put" erahnen, weil "put unlock" gar nicht die "avanti"-Markierung
traegt, bei der Beschreibung von "set rec fre"/"set unlock" lassen
sich die a99 und acon-Aspekte m.E. aber nur entwirren, wenn man eh'
schon alles weiss. Mir ist uebrigens nicht mehr klar, ob a99 und/oder
acon noch das automatische Entsperren am Job- oder Flex-Ende
durchfuehren und ob es wirklich noch gerechtfertigt ist, dass sich
die put's anders verhalten: Es ist natuerlich klar, dass acon-Jobs
eher kurzlebig sind (maximal einige Stunden oder Tage), wohingegen
a99 Sitzungen abhaelt (minimal einige Zehntelsekunden), in denen
typischerweise viele unabhaengige Flexe ausgeloest werden. Ob das aber
Konsequenzen fuer Datensatzsperren haben sollte, weiss ich nicht:
Wenn ein Job gesperrte Datensaetze zuruecklaesst, halte ich das
fuer schlechten Stil, aber notfalls muss man einen Reparaturjob
hinterher schicken. Aber wenn ein Flex dasselbe tut, kann man
dann wirklich erwarten, dass der Bearbeiter im gleichen a99-Fenster
irgendwann den hypothetischen Folge-Flex ausloest, der die Sperre
zuruecknimmt? 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.


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

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk3gMacACgkQYhMlmJ6W47M3+wQAhgJ0AcV9fXKxnq+VKxcHK1d7
wQzhho9SArWRl3CIgQp1YpG9SRE4mC8zmem04hJpVz+lk5jcM8nXAnDekzcDguXC
4QsDD9OAJy9Cvw8kepwPnE4AXd/t79ccl2n/3C9RvZSP1AHsNy3TC1k4wC2m+a22
nJ45wpYYsnKFCViijUo=
=77MK
-----END PGP SIGNATURE-----