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

[Bernhard Eversberg]

Am 01.06.2012 16:29, schrieb Sibylle Koczian:
>>
>> 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?
>
Dann werden die nachträglich, kurz vor dem Speichern, ermittelt.
Also nicht, wie bei "get edit..." schon prophylaktisch vor dem
Bearbeiten.
Und zwar geht das so:
-- Befehl put kommt
-- tbl wird gesperrt
-- Satz wird gesperrt
-- Zeitstempel wird geprüft: Ungleich -> Ende und Fehlermeldung
       "E: Sorry, rec ... was changed by somebody else"
    [update.job merkt das und protokolliert den Satz in "upro"]
-- Schluessel des gespeicherten Satzes werden errechnet
    (Der ist ja dann unverändert gegenüber dem Zeitpunkt des Ladens
     VOR der Bearbeitung!) [Er wird in ein anderes Satzobjekt geladen,
     damit keine Interferenz mit dem bearbeiteten Satz entsteht]
-- Schluessel werden verglichen mit dem Zustend im Arbeitsspeicher,
    also NACH der Bearbeitung, und entsprechend behandelt (gespeichert
    bzw. gelöscht in der Indexdatei)
-- Satz wird geloggt
-- Satz wird gespeichert, dabei freigegeben, TBL auch wieder freigegeben

Und wozu dann überhaupt noch die Befehle "get edit ..."? Für den Fall,
daß man auf ganz und gar keinen Fall jemals eine Fehlermeldung
"E: Sorry, rec ... was changed by somebody else"   erleben will.
Zeitweise hatten wir, vielleicht fälschlich, den Eindruck, daß diese
Option diesem oder jenem als conditio sine qua non gelte. Also, nun
ist sie da.

> 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.
>
Dann testen Sie jetzt lieber, bevor Sie sich voll auf unsere Aussagen
verlassen! Vielleicht gibt's ja bei Ihren Daten und Prozeduren noch
Dinge, die unserer Voraussicht entgangen sind. Sie müssen nicht
befürchten, daß Datensätze verfälscht werden, sondern allerhöchstens,
daß irgendwelche Schlüssel hinterher falsch sind oder fehlen. Unsere
Tests waren in der Hinsicht alle sauber, sonst hätten wir nicht
freigegeben. Aber wie gesagt, nach allem was wir schon erlebt haben ...

B.E.