PDA

View Full Version : Trigger auf Record Lock



Seiten : 1 2 [3] 4

bofrost
25-08-11, 12:49
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.

Die alten Anwendungen waren auf Grund von Einschränkungen wie z.B. die Begrenzung des Platzes durch die Emulation von den Abläufen sehr einfach und synchron. Alle Prozesse sind nach einer strikten Reihenfolge abgelaufen. Es wurde auf dem Bildschirm entweder eine Tabelle zum Blätter angezeigt oder ein Satz zum Editieren. Deswegen war es auch möglich, dass das ganze Programm auf den Datensatz wartet.

In den neuen Anwendungen können mehrere UI-Elemente gleichzeitig angezeigt werden. Diese müssen auch ständig mit Daten versorgt werden. Würde ich im Programm auf eine Satzsperre warten müssen, würde der User die anderen UI-Elemente eventuell nicht mehr bedienen können.

AS400.lehrling
25-08-11, 12:56
In den neuen Anwendungen können mehrere UI-Elemente gleichzeitig angezeigt werden. Diese müssen auch ständig mit Daten versorgt werden. Würde ich im Programm auf eine Satzsperre warten müssen, würde der User die anderen UI-Elemente eventuell nicht mehr bedienen können.

Könnte da nicht übel zwischen hacken und jeden usr mehrere Virtuelle unter usr zuordnen :confused:

Dann ließe sich jeder Anzeigebereich quasi als eingen ständige 5250 emu einrichten.

Wie gesagt übler hack :(

AS400.lehrling

Fuerchau
25-08-11, 13:16
Dann musst du dir eben dein Design wohl noch mal überlegen.
Wie funktioniert denn deine neue Anwendung wenn gar keine Satzsperren vorliegen würden ?
Was machst du dann mit konkurierenden Updates (letzter gewinnt) ?
Wenn du dieses Problem mal durchdacht und dann gelöst hast, ist die Satzsperre kein Problem mehr, da eine Sperre beim Update (bzw. dem vorherigen Lesen) ja die selbe Situation auftritt als hätte ein anderer User den Satz gerade vorher geändert.
In diesem Fall gilt die Satzsperre für den aktuellen User genauso als wenn der Satz gerade geändert wurde.

Wuntvor
25-08-11, 14:26
Die alten Anwendungen waren auf Grund von Einschränkungen wie z.B. die Begrenzung des Platzes durch die Emulation von den Abläufen sehr einfach und synchron. Alle Prozesse sind nach einer strikten Reihenfolge abgelaufen. Es wurde auf dem Bildschirm entweder eine Tabelle zum Blätter angezeigt oder ein Satz zum Editieren. Deswegen war es auch möglich, dass das ganze Programm auf den Datensatz wartet.

In den neuen Anwendungen können mehrere UI-Elemente gleichzeitig angezeigt werden. Diese müssen auch ständig mit Daten versorgt werden. Würde ich im Programm auf eine Satzsperre warten müssen, würde der User die anderen UI-Elemente eventuell nicht mehr bedienen können.

Die "alte" Anwendung stellt durch seinen Ablauf/Satzsperren Datenintegrität sicher. Der User der an einem Datensatz arbeitet kann sicher sein, daß seine Tätigkeiten auch den Zustand der Daten verändern, evtl. Nachfolgearbeiten bekommen dementsprechend stets korrekte Daten zur Verfügung gestellt.

Während die Applikation in dieser Art und Weise verfährt, soll dein Browserprogramm nun die Regeln verändern, womit du automatisch Probleme erhältst, die die "alte" Applikation nie hatte.

Wenn dein Browserprogramm auf Satzfreigaben wartet oder besser gesagt ebenfalls Satzsperren durchführt - sich also der Applikationslogik anpasst - kannst Du sicherstellen, daß die erfassten Daten auch tatsächlich gespeichert werden, da es ja keine konkurierenden Updates geben kann.

Sofern du dem User die Erfassung der Daten gestatten willst und diese dann, aufgrund einer Satzsperre, notgedrungen asynchron speichern willst, wirst du entscheiden müssen welche Datensatzänderung denn nun gespeichert werden soll. Bedenke hierbei, daß dies beliebig viele Änderungen sein könnten.

Herr Fuerchau hat mit seiner Analyse vollkommen recht.

PS : Mich würde auch interessieren was dein Browserproggi macht, sofern überhaupt keine Satzsperren vorhanden sind.

bofrost
25-08-11, 14:50
Könnte da nicht übel zwischen hacken und jeden usr mehrere Virtuelle unter usr zuordnen :confused:

Dann ließe sich jeder Anzeigebereich quasi als eingen ständige 5250 emu einrichten.

Wie gesagt übler hack :(

AS400.lehrling
Hm... das erinnert mich an die Anwendung die ich dem Letzt im Reisebüro gesehen habe :D Die arme Frau hinter dem Bildschirm hat sich damit ganz schon schwer getan :(

Naja "übel" und "hack" hören sich für mich nicht ganz so überzeugend an ;)
aber bei mir geht die Kommunikation ja eh nicht mehr über 5250 sondern über websockets und json Daten. Man kann natürlich weiter JOB's starten, nur dass stell ich mir schwierig vor die alle zu verwalten und miteinander kommunizieren zu lassen. Und Threads gehen leider auch wegen dem JobAccounting nicht :mad:


Wie funktioniert denn deine neue Anwendung wenn gar keine Satzsperren vorliegen würden ?
Was machst du dann mit konkurierenden Updates (letzter gewinnt) ?
Naja letzter gewinnt ist ja wohl keine Lösung, sondern nur das was passiert, wenn man sich gar nicht drum kümmert...

Also am Anfang wollte ich den Satz auch sperren lasse, wenn ein User in editiert.

Nehmen wir an wir haben eine Tabelle mit Sätzen und daneben ein Formular, dass die Details anzeigt und die Möglichkeit bietet den Satz zu editieren. Markiert der User einen Satz in der Tabelle soll er gelesen werden und im Formular angezeigt werden, durch einen Button gelangt der User in den bearbeiten Modus.
Klickt ein anderer User auf denselben Satz wird dieser auch angezeigt klickt er auf den Bearbeiten-Button soll über dem Formular die Information angezeigt werden, dass der Satz gesperrt ist und darauf gewartet wird bis der Satz wieder frei ist. Möchte der User aber nicht warten und mit einem anderen Satz weiter machen kann er den einfach in der Tabelle anklicken.

Das geht aber nicht, wenn das Programm auf den LOCK wartet! Weil der Prozess blockiert wird und die GUI nicht mehr reagiert...

Also müsste ich die Wartezeit auf den Recordlock heruntersetzen wie du mir ja schon des Öfteren vorgeschlagen hast.

Dann würde es aber nicht mehr funktionieren auf Satz zu warten...

Also anscheinend gibt es hier keine Universallösung die wirklich komfortabel für die User ist.

Vlt sollte ich für dateien, die nur von neuen Anwendungen verwendet werden eine komfortable Lösung bauen und beim zugriff auf eine nach der alten Methode gesperrten Datei bekommt man einfach die Fehlermeldung: "Satz wird von Hans Jürgen gesperrt, bitte versuchen sie es später nocheinmal."

Fuerchau
25-08-11, 15:01
Wenn der User ja die Entscheidung trifft auf den Satz zu warten, kannst du doch über eine Schleife mit kleinem Delay (läuft doch auf dem Web-Client?) z.B. alle 100ms versuchen die Satzsperre (bei *immed) zu erhalten bis es klappt. Hier hat der User sogar noch die Eingriffmöglichkeit den Wartevorgang abzubrechen.

Ein Batchjob oder Thread hilft da ggf. auch nicht, da ein anderer Job trotzdem den Satz vorher erhalten könnte (Job A Wartezeit abgelaufen, Job B noch wartend, Job A macht neuen Chain und liegt nun hinter Job B in der Lock-Queue).

AS400.lehrling
25-08-11, 15:33
Hm... das erinnert mich an die Anwendung die ich dem Letzt im Reisebüro gesehen habe :D Die arme Frau hinter dem Bildschirm hat sich damit ganz schon schwer getan :(

Naja "übel" und "hack" hören sich für mich nicht ganz so überzeugend an ;)
aber bei mir geht die Kommunikation ja eh nicht mehr über 5250 sondern über websockets und json Daten.

Wenn du eh schon Javascript benutzen möchtest weshalb nicht gleich komplett in Java & Client seitig mit Standard WebPlugin Arbeiten ?

Quasi das weiterführen was IBM mit WebShare probiert hat;)

Java läuft auf der i ja Serverseitig, müsste man nur schauen wie man sql Abfragen ins Java bekommt.

Oder liege ich jetzt völlig falsch:confused:

Gruß AS400.lehrling

camouflage
25-08-11, 15:55
Vielleicht versuchst du es mal mit dem hier...
Midrange Guru - OS/400 Edition (http://www.itjungle.com/guruo/mgo011802-story02.html)

bofrost
26-08-11, 07:20
Wenn der User ja die Entscheidung trifft auf den Satz zu warten, kannst du doch über eine Schleife mit kleinem Delay (läuft doch auf dem Web-Client?) z.B. alle 100ms versuchen die Satzsperre (bei *immed) zu erhalten bis es klappt. Hier hat der User sogar noch die Eingriffmöglichkeit den Wartevorgang abzubrechen.
Ja werd ich wohl so machen müssen, halte zwar nichts von lösungen bei denen der client immer nachschauen muss ob ein Status eingetreten ist.. aber wenns nicht ander geht...
Das würde dann im RPG-Client-Programm laufen, der Webpart ist nur reine Anzeige "ohne" Logik.


Wenn du eh schon Javascript benutzen möchtest weshalb nicht gleich komplett in Java & Client seitig mit Standard WebPlugin Arbeiten ?

Quasi das weiterführen was IBM mit WebShare probiert hat;)

Klar könnte man alles in Java schreiben, wir haben uns auf grund der großen know-hows in rpg allerdings dafür entschieden weiter RPG zu programmieren.


Vielleicht versuchst du es mal mit dem hier...
Midrange Guru - OS/400 Edition (http://www.itjungle.com/guruo/mgo011802-story02.html)
Ja so ähnlich würde ich's dann machen den Recordlock abzufragen.

Danke noch mal an alle für die Hilfe und die Geduld!

BenderD
26-08-11, 07:45
... wenn ich das alles zusammen richtig verstehe, habt ihr ein Web basiertes User Interface, das über Java Script Teile eine Event driven Anwendung darstellen soll.
Dahinter hängt dann ein (in Zahlen 1 ?) RPG Programm, mit dem dann die Kommunikation über DataQ erfolgt und das Problem besteht jetzt darin, dass das UI autistisch wird, wenn das RPG Programm in eine Wartebedingung geht?
Das ist aber dann doch auch so, wenn das RPG Programm für etwas ein wenig länger braucht.
D*B