[Allegro] Vb.246: V32.4 ist da (jetzt aber wirklich)

[Sibylle Koczian]

Lieber Herr Eversberg, liebe Liste,

Am 01.06.2012 08:27, schrieb Bernhard Eversberg:
>
> Verlautbarung 246 der Entw.Abt. 2012-06-01
> -------------------------------
> 2., ueberarb. u. angereich. Ausg.
>
> V32.4 ist da
> ============
>
...
>
> acon: Satzsperren (komplette Beschreibung siehe "set lock" in h xset)
> ----------------- [Achtung: *Nur acon*, nicht a99!]
>
> Die Befehle get edit first, get edit next, get edit last,
> get edit prev taten nicht ganz so, wie sie sollten. Nun sperren sie den
> jeweiligen Satz und legen eine Kopie seiner aktuellen Registereintraege
> an. Nun kann man sich Zeit lassen ...
> Das passiert auch mit f1nd ..., wobei ja ein bestimmter Satz geladen
> wird.
> Dies wurde eingerichtet, damit man ganz sicher gehen kann, dass
> zwischen dem Laden und Speichern kein anderer Prozess denselben Satz
> veraendert speichern kann.
> Nach jedem dieser Befehle koennen beliebige Aenderungen an dem Satz
> folgen, und:
> Mit simplem "put" speichert man ihn am Ende; dabei wird mittels der
> vorher kopierten Indexeintraege ermittelt, welche Schluessel geaendert
> werden muessen in der Indexdatei, und diese Aenderungen werden
> ausgefuehrt, der Satz bei der Speicherung wieder freigegeben.
> Soll das Speichern jedoch entfallen, muss man nun nicht mehr
> ausdruecklich "set unlock" geben, bevor man den naechsten find- oder
> get-Befehl absetzt. Frueher blieb der Satz sonst gesperrt, jetzt wird
> er automatisch wieder freigegeben. [acon hat keinen Offline-Speicher
> wie a99, es ist jeweils nur ein Satz geladen.]
>
> Manchmal will man es etwas anders: (nur in acon)
> NEU: set getlock on [gilt bis zum Ende des Jobs]
> Setzt *jedesmal* Satzsperre, wenn ein Satz geladen wird. Dann ist
> die Angabe edit in den get-Befehlen unnoetig. Und
> set getlog off
> schaltet die Setzung wieder ab.
>
> NORMALERWEISE aber braucht man sich gar nicht mehr um's Sperren zu
> bekuemmern! Man nimmt einen Satz her, aendert was, speichert ihn mit
> "put", und weiter zum naechsten! Was passieren kann, ist nur, aber
> ganz sicher hoechst selten, dass waehrend des Aenderns jemand anders
> denselben Satz geaendert und gespeichert hat. Dies jedoch erkennt
> acon dann am geaenderten Zeitstempel. Direkt an das "put" braucht
> man nur eine Zeile "if no ..." einzufuegen, um die Problemsituation
> zu erkennen und darauf zu reagieren.
> Das bisherige "set lock" und "get edit" kann man sich also auch
> sparen, es funktioniert aber weiterhin, d.h. Aenderungen an "alten"
> Jobs sind nicht noetig.
>

Da ist mir jetzt eines unklar: nach dieser Beschreibung werden nur bei 
"get edit ..." die Registereinträge kopiert. Und diese Kopie ist ja 
wirklich nur erwünscht, wenn der Satz geändert werden soll.

Die Beschreibung bei "NORMALERWEISE" verstehe ich so, dass hier "get 
edit ..." nicht verwendet wird, sondern einfach "find", "first", "next". 
Das wäre dann die Situation, in der nicht jeder Satz geändert wird und 
ein prophylaktisches Berechnen der Registereinträge unerwünscht wäre. 
Wenn man jetzt aber im Einzelfall doch geänderte Sätze speichert, was 
ist denn dann mit den Registereinträgen?

Was habe ich da falsch verstanden (oder was fehlt im Text)? Um 
gleichzeitige Bearbeitung von Sätzen geht es mir jetzt nicht (mehr), 
aber Acon-Jobs, die in die Datenbank schreiben, habe ich eine ganze 
Menge und ich habe mich bisher immer blindlings darauf verlassen, dass 
da mit den Registereinträgen nichts Ungutes passiert.

Beste Grüße,
Koczian