[Allegro] acon + update.job neu bereitgestellt

[Bernhard Eversberg]

Am 27.04.2012 08:43, schrieb Thomas Berger:
>>
>> -- acon macht selber vor dem Speichern die globale Manipulation,
>>     wenn ein Export eingestellt ist und eine Marke #-# enthält
>>     Dies kann aus  update.job  somit raus.
>
> was passiert, wenn es drin bleibt?
>
Kommt drauf an, was die Prozedur tut! Sie wird ja dann zweimal 
ausgeführt. Gäbe es einen Grund, den bisherigen update.job weiter
zu nutzen? Sie könnten das sogar machen, dann aber die Sprungmarke
anders nennen, so daß acon dann nichts täte.

>
>> -- update prüft vor dem "put", ob der Satz gesperrt ist. Wenn ja,
>>     wird nichts weiter versucht, sondern der Satz in  upro  kopiert
>>     mit entsprechender Meldung
>
> Nicht nur PRESTO, sondern auch andere allegro-Module koennten einen
> Satz gesperrt haben, schliesslich gibt es die entsprechenden
> Funktionen in der Flex-Sprache. Insofern sollte dieser Test entfallen.
Er *kann* entfallen. Was wir erst mal rausgenommen haben, ist der
mehrfache Versuch mit Zeitverzögerung.

> (Bzw. "upro": bezog sich dieser Abschnitt auf das Flex-Kommando
> "update"?)
Das kommt im  update.job  nicht vor.

>
>> -- Die Put-Funktion im Innern der Klassenbibliothek
>>     (AwPut() in abase.cpp) prüft ihrerseits auch nochmal, das
>>     dauert allerdings länger, und gibt im Negativfall eine
>>     Meldung, die ebenfalls zum Nichtspeichern und Protokollieren führt.
>
> Das kann dann im update.job aber abgefangen werden, so dass
> automatisch ein naechster Versuch startet?
Das könnte man so machen, haben wir jetzt aber noch nicht gemacht.
Es wird eine Meldung in upro ausgegeben nebst dem Satz.

>
> Hier schon oft angesprochen und begruendet: Das Standardverhalten sollte sein,
> dass update (nicht "put") es immer weiter versucht, auch auf die Gefahr des
> "Aufhaengens".
>
Darüber kann man nochmal reden, im update.job jedenfalls kommt "update"
nicht vor, nur "put".

>
>> Die nötigen Sperrungen, m.a.W., erfolgen jetzt nur noch intern, darum
>> braucht man sich nicht mehr zu kümmern.
>
> Das KANN nicht funktionieren: Wenn in den entsprechenden Update-Modi
> Saetze gemergt werden, muessen ihre "online"-Versionen beim
> Einlesen gesperrt werden, beim (waehrend des) "put" ist es zu spaet.
>
Beim "put" wird der Zeitstempel geprüft, vergessen Sie das nicht! Bei 
Ungleichheit keine Speicherung, sondern Meldung und Kopie des Satzes in
upro. Wenn also zwischen Einlesen und "put" was passiert war, wird das
abgefangen, und zwar ja nun auch, wenn's weniger als 1000 Millisekunden
waren.

>
>> Reservierung oder sowas wie "set lock" oder "get edit" erübrigt sich
>> damit im update.job!
>
> Und was passiert, wenn es drin steckt?
>
Weiß ich nicht. In der neuen Version steckt es nicht drin.

>
>> Nebenbei:
>> Das alte UPDATE.EXE warf die Meldung "Satz gesperrt" aus, wartete
>> ein wenig, usw. Nur Freigabe des Satzes durch den Admin führte zur
>> Weiterarbeit. Falls das für besser gehalten wird, könnten wir
>
> Nur so kann man sich darauf verlassen, dass nach dem Ende des Updates
> alles geschehen ist, was haette geschehen sollen.
>
Kommt drauf an! Wenn der PRESTO-Nutzer gerade einen Satz änderte und
dieser dann vom "put" nochmals geändert wird, geschieht u.U. nicht das,
was geschehen hätte sollen. Ist es da nicht besser, wenn der Satz in
upro landet und man sich das nochmal anschauen muß/kann, anstatt sich
blind drauf zu verlassen?

B.E.