Re: [Allegro] Lock/unlock-Mechanismen (war: update.job + optsget.inc überarbeitet)

[Thomas Berger]

Lieber Herr Eger, lieber Herr Eversberg,

>>> Es ist schon schlimm genug, dass ich kein "put" ausführen kann, ohne
>>> damit den Lock-Status des Datensatzes zurückzusetzen.
>>>
>> Das könnte optional geändert werden, vielleicht mit "put lock".
> 
> Gute Idee. Dann dürfte auch das Laden eines nächsten Satzes
> keine Freigabe bewirken (vergl. xget.rtf#get edit).

Ich glaube, dass a99 und acon wirklich wissen muessen, ob eine
Datensatz- oder Datenbanksperre vom aktuellen Prozess bewirkt
wurde oder nicht. Dann kann ein "put" auch einfach so
implementiert werden, dass hinterher der Zustand dieser beiden
Sperren exakt so ist wie vorher:

1.) Besitze *ich* die Sperre(n) bereits? --ja--> Speichern ohne
        |                        Ruecksicht, alle Sperren belassen
      nein
        |
2.) fehlende Sperre(n) erlangen  --klappt--> Speichern, erlangte
        |                                    Sperren ruecksetzen
    klappt fuer mindestens eine nicht
        |
3.) Erlangte Sperren ruecksetzen, Aktion als verweigert quittieren


Fuer den Job-Programmierer gaelte dann die Ansage, dass ein
explizities Sperren per "set rec lock" oder "set tbl lock"
stets ein explizites Gegenstueck benoetigt.

Man kann dann ueber Abkuerzungen wie "get edit" (also "sperren und
einlesen") nachdenken [eine ziemlich wichtige Sache, denn erst nach
einem "get" bin ich in der komforatblen Position, ein "lock" *formulieren*
zu koennen, strenggenommen muss ich danach ein erneutes "get" veranstalten,
um "sauber" zu bleiben], ob naemlich "put" und "undo" optionale
Argumente spendiert bekommen sollen, die *im Erfolgsfall* die
gleichzeitige Ruecknahme von Satz- und/oder Datenbanksperren bewirken.

viele Gruesse
Thomas Berger