View Full Version : Trigger auf Record Lock
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.
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
Im Grunde kannst Du tatsächlich nur verfahren wie die Altanwendung es macht, so bedauerlich es auch sein mag.
Bei jeder anderen Lösung ist dem Anwender nämlich garnicht bekannt was er eigentlich ändert. Der Record Lock bedeutet, daß der eingelesene Datenbestand bei Auflösung der Sperre nicht mehr dem ursprünglich eingelesenen entsprechen muss.
Hier hilft nur Sperren und Lesen um diesem Problem aus dem Wege zu gehen.
Sollte dieses Problem nicht von Interesse sein, so besteht natürlich bei Auftreten der Satzsperre die Möglichkeit der Auslagerung der Speicherung in eine externe Batchfunktion. Dies verschärft die oben beschriebene Problematik jedoch noch und ist daher eigentlich grundsätzlich abzulehnen.
Natürlich könnte dein "Browser" Proggie auch auf die Satzfreigabe warten und durch erneutes Lesen des Datensatzes und Abgleich mit den editierten Daten auftretende Probleme kenntlich machen. Dies ist natürlich abhängig von der Wartezeit, wäre aber wenigstens argumentativ zu vertreten.
Wie bereits erwähnt wirst Du über kurz oder lang dieses Problem grundsätzlich beheben müssen. Ich bin mir sicher, daß die User dir dies des öfteren präsentieren.
Natürlich könnte dein "Browser" Proggie auch auf die Satzfreigabe warten und durch erneutes Lesen des Datensatzes und Abgleich mit den editierten Daten auftretende Probleme kenntlich machen. Dies ist natürlich abhängig von der Wartezeit, wäre aber wenigstens argumentativ zu vertreten.
Das ist eine super Idee ich könnte nach dem klicken auf Speichern auf die Satzsperre warten und prüfen ob der Satz verändert wurde und dann dem User nochmals entscheiden lassen, was er wie ändern möchte.
Allerdings möchte ich nicht, dass das Programm solange stillsteht. Somit bin ich wieder am Problem vom Anfang, wie bekomm ich einen RecordLock per Trigger o.ä.
Ich hab bis jetzt 3 Lösungsansätze:
1.)Einen zweiten Thread auf machen, welcher auf die Satzsperre wartet. Hier Stellt sich mir allerdings das Problem, das das Job-Accounting nicht mehr funktioniert. (CHGACGCDE)
2.)Einen zweiten JOB submitten der den Record-Lock wartet und dann über die DTAQ dem Ursprungsjob mitteilt, dass der Record gerade frei war... Hier könnte aber jemand schneller sein und man müsste neu anfangen oder man würde es irgendwie schaffen den RecordLock so von einen Job zum anderen zu bringen, dass er dazwischen nicht abhanden kommt. Ich bin mir nicht sicher ob man das mit Lock-Spaces lösen kann.
3.)Über eine art Trigger, Exit-Point-Programm meinen Programm mitteilen, dass der Record-Lock aufgehoben wurde. (Ich hab eine ähnliche Umsetzung, dass bei Dateiänderung automatisch die View aktualisiert wird, funktioniert ohne Probleme) Hier hab ich allerdings noch keine Möglichkeit gefunden wo man so einen Trigger-Programm ansetzen könnte. (Gibt es eine Tabelle in der alle Locks gespeichert werden wie bei andern DB2 Systemen?)
Du kannst die Satzwartezeit auf 0 reduzieren !
Hierzu einfach einen OVRDBF FILE(MYFILE) WAITRCD(*IMMED) vor Programmstart (bzw. Open) im Job durchführen (habe ich oben schon mal erwähnt).
Dann brauchst du den ganzen anderen Kram nicht da du nicht wartest und sofort über die Satzsperre bescheidweißt.
Diesen ganzen anderen Schmonz brauchst du nicht!!!
Was die Locktabelle angeht, so kann man diese nur per API abgreifen.
Und nicht jede Datenbank hat eine Locktabelle als TABLE in der DB sondern arbeitet vernünftigerweise mit Semaphore oder ähnlichen sog. Atom-Funktionen.
... so fangen Altlasten an:
- man mixe alle Schlagworte, die gerade aktuell sind miteinander
- man gehe allen Standards aus dem Weg
- man übernehme alle Schwächen aus Altsystemen
- erst programmieren, dann überlegen
- wenn man auf Probleme stößt, schlägt man den kompliziertesten Wege ein, um sein Knowhow unter Beweis zu stellen
D*B
Nun ja, anders kann ich mich bei meinen Kunden auch nicht
a) profilieren
b) unabkömmlich machen
c) das große Geld machen
:p :p :p :p :p :p :p :p :p
AS400.lehrling
24-08-11, 22:38
Weshalb wird versucht den Gaul von hinten zu Satteln :confused:
1800 Anwendungen die wahrscheinlich schon seit 20 Jahren Arbeiten können nicht falsch liegen.
Bin mir ziemlich sicher das die Anwendungen unter CA oder WebShare genauso funktionieren wie auf einen GreenScreen ;)
Probier doch mal aus wie es unter TN5250 oder Holgers Version funktioniert.
Holgers Version dürftest du hier finden Rechenzentrum Kreuznach - die AS/400-Profis (http://www.rzkh.de)
Es ist meiner Meinung nach ein Fehler in Browser Plugin bzw PGM das verwendet werden soll.
Bei Irrtum bitte korrigieren :p
Gruß AS400.lehrling
Du kannst die Satzwartezeit auf 0 reduzieren !
Klar das muss ich sowieso, wenn der Client sofort antworten muss... aber das ändert am Ablauf trotzdem nichts... entweder ich lass den Ablauf gleich und sperr die Sätze während der eingabe oder ich bring beim Speichern die Meldung "hallo lieber User deine Arbeit war um sonst!"
1800 Anwendungen die wahrscheinlich schon seit 20 Jahren Arbeiten können nicht falsch liegen.
Bin mir ziemlich sicher das die Anwendungen unter CA oder WebShare genauso funktionieren wie auf einen GreenScreen ;)
Ja so langsam bin ich auch am Zweifeln ob es so schlimm ist, wenn ein Prozess etwas länger die Satzsperre hält... das funktioniert sogar schon seit über 20 Jahren so ;)
Klar das muss ich sowieso, wenn der Client sofort antworten muss... aber das ändert am Ablauf trotzdem nichts... entweder ich lass den Ablauf gleich und sperr die Sätze während der eingabe oder ich bring beim Speichern die Meldung "hallo lieber User deine Arbeit war um sonst!"
Nein. Prüfe die Satzsperre vor Arbeitsbeginn und dann braucht der User auch nicht erst nach getaner Arbeit benachrichtigt werden. Alles andere verbietet sich sofern die Satzsperre durch interaktiver User-Arbeit erzeugt wird. Da ist die Wartezeit nämlich unbekannt und kann durch zwischenzeitliches Mittagessen auch gerne ausgedehnt werden.
Ja so langsam bin ich auch am Zweifeln ob es so schlimm ist, wenn ein Prozess etwas länger die Satzsperre hält... das funktioniert sogar schon seit über 20 Jahren so ;)
Vor 20 Jahren war das nicht weiter wild, da nahezu alle Applikationen so verfuhren. Heutzutage ist dies nicht mehr State-of-the-Art und du solltest Dich mit der Analyse bezüglich einer Änderung beschäftigen.
Um es klar zu sagen, jede hier angesprochene Zwischenlösung ist Gurke.
Ein Batch-Job der eine interaktive Änderung in einem zeitlich unbestimmten Rahmen durchführt ist .... naja.... suboptimal. Der Verlust der Synchronität sollte vermieden werden. Denke immer daran, daß dem ändernden User ja mitgeteilt werden muss, daß die Daten geändert wurden oder geändert werden können. In beiden Fällen muss er dies überprüfen/arbeiten, da dem User nicht bekannt ist, inwiefern er die letzte Änderung durchführte oder ob evtl. seine Änderung erneut überschrieben wurde.
Deine wirkliche Altlast sind die anhaltenden Satzsperren. Diese Logik behältst Du bei oder Du änderst die Altlast. Alle Tricks um dieses Problem zu umgehen wird zu - und da stimme ich Herrn Bender zu - vergrößerten Problemen führen. Da Du ja aber zeitliche Probleme hast, 1800 proggis anzupassen-sofern dies überhaupt möglich ist- mag eine "Zwischenlösung" sinnvoll sein.
Da die aktuelle Applikation Wartezeiten vorweist stellt sich mir die Frage warum das Browserprogramm dies nicht dürfen sollte. Dies wäre dann nämlich keine Zwischenlösung sondern der Applikation angepasst.