View Full Version : Maximale Satzwartezeit
Hallo,
ich möchte beim Chain eine Satzsperre abfangen.
In der Datei sind viele Zugriffe von vielen Usern wie lesen, schreiben, updaten und löschen.
Mit CHGPF FILE(Lib/BestellF) sehe ich das bei der Satzwartezeit mit 60 Sekunden belegt ist.
Falls ich das jetzt auf *IMMED ändere, was habe ich für Vor bzw. Nachteile?
Wie definiert ihr so die Satzwartezeit bzw. fragt die Sperren ab?
Gruß Tarki
Maximale Dateiwartezeit . . . . *IMMED Zahl, *SAME, *IMMED, *CLS
Maximale Satzwartezeit . . . . . > 60 Zahl, *SAME, *IMMED, *NOMAX
Hi,
die Satzwartezeit veranlasst das System bei einem
Recordlock diese Zeit zu warten um danach die Meldung
an dein Programm zu senden.
Wenn keine Wartezeit definiert ist, erhält dein Pgm die Meldung direkt.
Gruss
Michael
dschroeder
13-02-13, 15:45
Hallo Tarki,
bei uns ist die Wartezeit in der Regel auch auf 60 Sekunden gesetzt. Manchmal ist das zu lange. Mit OVRDBF kann man die Wartezeit "fallbezogen" verändern, ohne sie global für die Datei zu ändern. Es kommt bei uns schon ab und zu vor, dass User auf einen Satz warten und dann reinkommen, wenn der sperrende User den Satz verlässt. Wenn wir den Wert auf *immed stellen würden, würde das System ja sofort einen Fehler schmeißen (bzw. das Programm sollte das natürlich abfangen).
Dieter
... naja, mit den default Wartezeiten da haben sich ein paar in Rochester zusammengesetzt und intensiv gemeinsam an nix gedacht: der Datei Wait steht auf immed und der Satzwait auf 60 sec. In korrekt programmierten Anwendungen dauert ein Record Lock ein paar Millisekunden und was nach 1 sec. nicht da ist, kann Stunden dauern - weil ein Hornochse (in Worten: Hornochse) oder eine Hornkuh (in Worten: Hornkuh) von Programmierer einen Satz mit Sperre liest und dann einen Bildschirm ausgibt, der auf eine Benutzer Eingabe wartet.
Wenn man Transaktions sicher arbeitet (also mit Commit Steuerung) kann man den Satz wait auf 2 bis 5 sec. setzen und wenn man gerade dabei ist, den File wait auf den doppelten Satz wait.
D*B
dschroeder
14-02-13, 09:25
Ich verstehe nicht, wie commit Steuerung das Sperrproblem lösen sollte. Wenn ich z.B. den Kunden nicht sperre, solange ein User daran arbeitet, würde ein weiterer User den Kunden ja gleichzeitig bearbeiten können. Das bedeutet, dass ich die Änderungen eines Users zum Schluss verwerfen müsste nach dem Motto: "Ätsch: Du hast zwar sehr viel erfasst, aber leider kann ich deine Änderungen nicht speichern, weil ein anderer User inzwischen etwas geändert hat". Das ist bei uns kein gewolltes Verhalten einer Anwendung. Wenn ich einen in Bearbeitung befindlichen Kunden bearbeiten möchte, bekomme ich eine Meldung "Der Kunde wird gerade von User xxx bearbeitet".
Dieter
andreaspr@aon.at
14-02-13, 10:32
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
14-02-13, 10:51
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
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.
Leider kenne ich den Begriff Sperrtabelle nicht.
Wie könnte ich mich in das Thema am besten einlesen?
lg
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 :).