Maximale Satzwartezeit

[andreaspr@aon.at]

Hallo,

Eine Satzsperre zu halten um sicher zu stellen, dass dieser von niemandem geändert werden kann ist generell keine gute Lösung.
Dafür sollte man sich andere Ansätze überlegen
*) Timestamp der letzten Änderung, wenn du wissen willst ob inzwischen ein User was geändert hat
*) Kennzeichen in der Tabelle setzen, wenn der Kunde gerade in Bearbeitung ist
*) etc. etc.

Was der andere Dieter gemeint hat, war dass durch CC eine Kette an Prozessen (Update, Delete, Insert) sicherer durchgeführt werden kann.
Jedoch wurde das hier eh schon öfters besprochen.

lg Andreas

[dschroeder]

Hallo Andreas,

danke für die Info. Ist schon klar, dass Commitment Control Transaktionen sicherer macht. Mir ging es darum, dass ich es nicht sinnvoll finde, mehreren User gleichzeitige Änderungen zu erlauben und diese später zu verwerfen. Dieses Konzept des "optimistic locking" halte ich für die meisten Anwendungen für nicht sinnvoll. Bzw. mir fällt im Moment überhaupt keine Anwendung ein, wo das sinnvoll ist. Es kann natürlich sein, dass ein anderes Verfahren schwieriger zu implementieren ist. (Z.B. Webanwendungen, in denen beliebige User ihre Anwendung mittendrin zuklicken). Als User fände ich es sehr frustierend, meine angefangene Änderung später nicht speichern zu können.

Dieter

[Fuerchau]

Hier hilft ein logische Sperrtabelle, auch für Transaktionen.
In diese trägt man seinen Sperrgrund ein und kann ebenso darauf prüfen.
Dieter hat dies schon des öfteren erklärt.
Mit AtExit-Methoden, Commit-Ressource o.ä. kann man auch bei abnormalem Ende des Jobs für das Aufräumen solcher Sperrgründe sorgen.

[tarkusch]

Leider kenne ich den Begriff Sperrtabelle nicht.
Wie könnte ich mich in das Thema am besten einlesen?

lg

[Fuerchau]

Das ist einfach eine Tabelle, die i.W. einen Schlüssel und einen Wert enthält.
Diese Tabelle kannst du ja mit einer Satzwartezeit von 1 Sekunde definieren.

Wenn du eine Ressource (z.B. Kunde) sperren willst, prüfst du, ob in dieser Tabelle der Satz bereits durch einen Eintrag gesperrt ist, ansonsten trägst du dich halt selber ein.
Das Ganze unter CommitControl, damit das eben sicher ist.
Beispiel:

if lesenForUpdate() = false;
if schreiben() = false;
// ein anderer war schneller
endif;
else;
UpdateSperre();
endif;
commit;

Machwas(); // Reminizenz an Dieter

deleteSperre();

Die Sperrmimik packt man am besten in eigene Programme mit eigener ACTGRP, damit man mit der eigenen Transaktion nicht in Konflikt kommt.

Literatur zu Anwendungslogik gibts da glaube ich nicht .