Trigger auf Record Lock

[bofrost]

Hallo zusammen

Ich würde gerne einen Trigger auslösen sobald eine Satzsperre aufgehoben wird um meinen Client-Programm mitzuteilen, dass der Satz jetzt zur Verfügung steht.
Gibt es eine elegante Lösung das zu bewerkstelligen ohne einen zweiten Job zu starten der auf die Satzsperre wartet? Ich hab da an Trigger oder Exit-Point Einträge bzw. APIs gedacht, konnte aber leider nichts Passendes finden.


Optimistisches Sperren kommt für mich leider nicht in Frage, da sonst alle Programme geändert werden müssten.


Danke schon mal im Voraus für die Hilfe

[BenderD]

... das riecht wieder mal nach zweitbester Idee! Das hat mit optimistischem oder pessimsitischen Sperren nix zu tun! Ein Record Lock, der eine User Transaktion übersteht ist ein ernsthafter Kunstfehler, der durch solche Workarounds noch verchlimmert wird.

D*B,

dem sich der Magen rumdreht, bei dem Gedanken an einen externen Lock-Monitor

[bofrost]

Ich möchte ja auch keine Record-Locks erstellen sondern nur auf bestehenden Sperren reagieren die von sehr langen Transaktionen gehalten werden.

An so einem externen Lock-Monitor hab ich auch schon gedacht, mir wär aber am liebsten wenn der Lock automatisch eine Art Trigger auslösen würde und ich nicht immer Prüfen müsste ob noch ein Lock vorhanden ist.

Gibt es den keine Exit-Points, Trigger, Systemdateien/Objekte oder APIs von denen man ein Programm aufrufen lassen kann wenn ein Record-Lock entfernt wird?

[Fuerchau]

Das gibt es tatsächlich nicht.

Du kannst tatsächlich nur per DSPRCDLCK regelmäßig eine Outfile erstellen, die du dann entsprechend auswerten kannst.
Für DSPRCDLCK gibts natürlich auch das passende API:
Retrieve Lock Information (QWCRLCKI) API
Retrieve Record Locks (QDBRRCDL) API

Allerdings funktioniert das nun mal nicht sehr zeitnah, wenn du die Satznummer des freigegebenen Satzes benötigst, da diese inzwischen schon wieder gesperrt sein könnte.

Ansonsten stimme ich Dieter zu, wofür soll das denn gut sein ?

Dein Client könnte doch selber in regelmäßigen Abständen den Lock auf den gesperrten Satz durch einen eigenen Lock prüfen.
Per OVRDBF kannst du die Satzwartezeit ja auch entsprechend reduzieren, so dass nicht immer 60 Sekunden gewartet werden muss.

[BenderD]

... das ist doch an allen Ecken krank, woher soll denn ein Prozess, der eine Sperre hält wissen, wer da auf ihn wartet? Bei korrekter Programmierung tritt das Problem nicht auf und Fehler gehören ausgebaut und nicht mit fragwürdigem Aufwand am Leben erhalten!

D*B

[bofrost]

Klar, das ziel ist natürlich die Fehler auszubauen und nicht eine Umgebung zu schaffen die sie toleriert. Allerdings ist es bei vielen Programmen wohl bis jetzt gang und gäbe die Satzsperre während der Benutzereingabe zu halten. Ich möchte mich jetzt auch nicht darüber streiten ob das sinnvoll ist oder nicht...
Fakt ist nur, dass es mir nicht möglich ist alle Programme sofort zu ändern aber ich trotzdem eine schnelle vlt. auch nicht die beste Lösung benötige.

Die Idee das über die Outfile zu machen halte ich für nicht so gut, wenn mir doch die APIs gleich die richtigen Informationen liefern.

Hatte gerade noch eine andere Idee wie ich an die Jobsperre komm ohne meinen JOB zu blockieren. Mein erster Gedanke war einen Thread zu machen der auf die Sperre wartet allerdings hat das JOB-Accountig Probleme mit Threads, deswegen würde ich einen 2. JOB starten, der sich die Satzsperre holt. Das Problem ist dann nur wie ich die Satzsperre zum Ursprungsjob zurückbekomme. Ich bin mir nicht genau sicher ob Lockspaces mein Problem beheben können? Ist es damit möglich einen RecordLock zwischen zwei jobs zu teilen?

[BenderD]

... da gibt s keine schnelle Lösung! Das führt nur alles weiter in den Sumpf - und ich würde auch davon abraten an sowas rumzubasteln; wenn man dann statt der Pest die Cholera am Hals hat, dann hat man ratzfatz den schwarzen Peter in der Hand.
Wenn du mal ein paar mehr Infos über die Programme rausrückst (RLA oder SQL, Commit oder keins, elementare Locks oder Deadlocks, eine oder mehrere Dateien betroffen), kann man da ja vielleicht ein paar Sanierungswege diskutiern.

API oder outfile gibt sich beides nix, ein lock kann schon wieder weg sei, oder ein anderer schlägt vorher zu... Falls es sich um greenscreen handelt, kannst du die Threads gleich wieder vergessen...

D*B

[Fuerchau]

Wo liegt denn eigentlich dein Hauptproblem ?
Satzsperren kann man auch ignorieren, wenn man per 2 Dateien arbeitet:
I-Datei zum sequentiellen Lesen, und U-Datei zum Chain/Update.
Mit verkürzter Satzwartezeit (OVRDBF) ist der Lock dann kein Problem mehr.

[bofrost]

Ok dann muss ich mal etwas ausholen, also im Moment läuft bei uns noch der Großteil der Anwendungen auf Green-Screen. In einer Anwendung soll nun eine Rich Internet Application entstehen.

Die alten Programme sind alle so programmiert, dass während der Benutzereingabe ein Record-Lock gehalten wird. (Es handelt sich um über 1800 Programme, bei denen die meisten nach dem oben genannten Prinzip auf Dateien zugreifen.)

Wenn jetzt ein Benutzer den neuen Teil der Anwendung im Browser aufruft, verbindet er sich per Websocket auf die AS400 und kommuniziert per DTAQ mit einem JOB. Ähnlich wie früher im Green-Screen wird die RIA von der AS400 aus gesteuert.

Klickt der User jetzt auf einen Satz um ihn zu editieren kann er ihn zwar anzeigen und editieren aber nicht abspeichern, wenn jemand anders ihn noch blockiert.

Dieses Verhalten kommt bei den Anwendern nicht sehr gut an, da es teilweise sehr aufwändig ist die Informationen die zum Bearbeiten nötig sind zu besorgen und die ganze Arbeit beim Speichern dann wieder zunichte gemacht wird.

Deswegen such ich jetzt eine Lösung die dem Anwender garantiert, dass er wenn er dem Satz zum Editieren öffnet ihn auch Abspeichern kann. Es ist aber auch wichtig, dass ich die 1800 Altprogramme nicht ändern muss.

[B.Hauser]

M.E. hast Du kaum eine andere Möglichkeit, als Deine Programme dahingehend zu ändern, dass:
1. Grundsätzlich im Input Modus einglesen wird
2. Nach dem EXTFMT (bzw. vor dem Einlesen der DataQueue) wird beim Ändern der Datensatz im Update Modus erneut eingelesen.

Die Änderungen sollten relativ leicht eingebaut werden können, ... allerdings wird auch das bei ca. 1800 Programmen ein paar Minütchen dauern.

Birgitta

[Fuerchau]

Da die Altanwendung so funktioniert musst du wohl oder übel genauso verfahren.
D.h., bevor der User den Satz editieren kann eben die Satzsperre setzen. Ist dies nicht möglich, kann der User gar nicht erst editieren!

Bei anderen Anwendungen mit sog. "logischen" Sperren wird ja auch nicht anders verfahren. Wenn der Vorgang (Satz, Beleg, Auftrag) gesperrt ist kann eben nicht bearbeitet werden.
Der User bekommt einen Hinweis und muss es selber eben später noch mal versuchen.

Wenn du in deiner RIA nicht ähnliche Methoden der Sperre verwendest kann es gerade hier ja zu konkurrenten Updates kommen.
Wenn der Satz frei ist und eben keine Sperre (wie auch immer realisiert)existiert können ja 2 oder mehr User diesen Satz bearbeiten und der letzte Update gewinnt!

Wenn ich mir mit .NET und einem DBDataAdapter den SQL-Update generieren lasse, wird in der Where-Klausel jedes einzelne Feld auf den vorherigen Inhalt überprüft und bei Ungleichheit der Update abgelehnt.
Ich muss nun die aktuellen Werte erneut abrufen, dem User die Änderungen ausgeben und ihn dazu veranlassen ggf. seine Änderungen zu wiederholen wenn von ihm geänderte Felder oder abhängige Felder nicht mehr den erwarteten Inhalt haben.

Gerade bei RIA's o.ä. muss man sich diesbezüglich sowieso von der alten Logik verabschieden.

[BenderD]

sind das tatsächlich konkurrierende Änderungen, oder werden auch in der Anzeige (der Altprogramme) Sperren gehalten und warum hat das denn vorher funktioniert? Da wurde doch mit den Altprogrammen wahrscheinlich dasselbe Geschäft gemacht?

D*B

@Baldur: das wäre das einzementieren eines Fehlers, was die "logischen" Sperren angeht, die sind im Unterschied zu Satzsperren Deadlock frei und werden ohne Wartezeit ausgelesen.

@Birgitta: das ist keine wirkliche Umstellungsperspektive

Um nur kurz einen Weg zu skizzieren:
Für die neuen Anwendungen braucht man ein sauberes Design mit Bearbeitungssperren (Baldur nannte das logische Sperren), diese Anwendungen müssen dann transaktionssicher mit Commitment Controll programmiert werden, damit keine logischen Sperren hängenbleiben können.
Für die Altanwendungen kann man die Beachtung der logischen Sperre, dann mit einem Trigger erzwingen, ohne dass diese die abfragen müssen.
Die erforderlichen Änderungen in der Datenbank kann man mit einem View Layer von der Altanwendung entkoppeln.

D*B