[Allegro] Avanti Lock-Mechanismus

[Anando Eger]

Hallo Herr Berger, Liebe Listenleserinnen und -leser,

On 30 Apr 2008 at 15:50, Thomas Berger wrote:

> |>> kennt jemand eine Möglichkeit, per avanti einen Satz so zu sperren,
> |>> daß diese Sperre nach Ende des aktuellen Jobs erhalten bleibt?
> |>>
> |> Nein, sorry, das ist nicht vorgesehen. Das Objekt "Record" enthält in
> |> seinem "Destruktor" den Release-Befehl.
> |> In a99 wird der umgangen. ...
> |
> | Ließe der sich nicht auch in avanti umgehen?
> | ...
> | Es würde also eine ungeheure Erleichterung darstellen, wenn ein Satz
> | zwischen zwei Jobs gesperrt bleiben würde ....
> | ...
> 
> Ich finde das problematisch: Wenn wir eine Form von persistenter
> Verbindung haetten (zwischen CGI-Skripts und Avanti gab es das
> einmal, zwischen Avanti-Server und seinen Client-Prozessen gab
> es das nie), dann koennte Avanti beim Verbindungsende Saetze
> automatisch entsperren und Locks ueber die Lebensdauer eines
> Einel-Jobs waeren moeglich. So sehe ich das Problem, dass
> Datensaetze bei Leitungsproblemen gesperrt werden und spaetere
> Jobs dann Timeouts oder Deadlocks erleiden.

Die Frage ist: welches Problem tritt häufiger auf? Wenn aus einer 
Web-Umgebung auf eine Datenbank zugegriffen wird, die im harten 
Ausleihbetrieb benutzt wird (Entleihungen/Rückgaben von mehreren 
Plätzen im Sekundentakt) ist die Warscheinlichkeit recht hoch,
einen "Treffer" (z.B. einen sich gerade ändernden Exemplarsatz)
zu landen. Die Lock sollten auch nur für kurz aufeinanderfolgende
Aktionen, typisch aus demselben Script heraus, eingesetzt
werden.
 
> Koennen Sie nicht auf Anwendungsebene eine Kategorie als
> "Bearbeitungssperre" einfuehren, wenn Sie hier einen Zeitstempel
> einsetzen, koennen Sie sogar noch ein eingebautes Verfallsdatum
> beruecksichtigen. 

... und in der, ich nenne sie mal "Soft-Sperre", auch noch die
Prozess-ID ablegen ...

Einen solchen Mechanismus habe ich schon bei WEB-Anwendungen im 
Einsatz, die nur Daten ändern, die nicht vom a99-Benutzer angefaßt
werden. Aber leider sind die Bedingungen nicht immer so günstig.
Die Auflösung der Zeitstempel müßte im Millisekundenbereich liegen - 
und - was mir schwerwiegender erscheint, alle betroffenen 
a99-Aktionen müßten auf einen solchen Mechanismus umgestellt werden.

> Diese Sperre ist dann je nach Anwendung ggfls.
> nur auf die Bearbeitung einiger Kategorien beschraenkt (ich
> gehe mal davon aus, dass Sie nicht so verwegen sein wollen,
> nach einer makroskopischen Zeit den kompletten Satz aus der
> Web-Anwendung heraus zurueckspeichern zu wollen 

Doch: 
Job 1: Satz lesen (und möglichst sperren)
... irgendetwas im Script tun ...
Job 2: Satz erneut laden - komplett mit neuem Inhalt versehen - 
       und speichern (update ist ungeeignet, da es sich am
       lock-Status stören würde)
Allerdings nur im Script-Laufzeitrahmen. Was ist warscheinlicher: 
eine Verbindungsstörung im 2. Job dieses Beispiels oder ein 
a99-Absturz auf irgendeinem PC im Netz beim Speichern ... ;-)

> sondern wissen, welche Kategorien Sie veraendern).

Klar, aber verallgemeinert bedeutet das: für jeden Geschäfts-
prozess einen monolithischen (Spezial-)Job mit der kompletten 
Funktionalität dieses Prozesses zu benutzen - dabei stößt man 
leider zu oft an die Grenzen der Job-Sprache 'Avanti-Flex' ...

Viele Grüße
Anando Eger

---------------------------------------------------------------------
Anando Eger Datenverarbeitung
Herr Dipl.-Ing. Anando Eger
Gustav-Voigt-Str. 24
01156 Dresden
Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
---------------------------------------------------------------------