Trigger auf Record Lock

[BenderD]

Ok also ist mein Problem eigendlich, dass Threads nicht mit CHGACGCDE funktionieren

Beim Starten wird eine Portal-App gestartet, aus der man weiter Programme Starten kann. Zwischen den einzelnen View's und den Jobs besteht dann immer eine 1 zu 1 verbindung.

Über die DTAQ können nicht nur Events verschickt werden sondern auch Prozeduren aufgerufen werden. Hier wird eine Rückantwort verlangt, die dann eine callBack prozedur auslösen kann.

Vlt sollte ich bei jedem event ein rotes X unten anzeigen und warten bis eine Antwort zurückkommt?

... der CHGACGCDE scheint mir nicht das Problem zu sein, der könnte ja im initial thread erfolgen, wenn ich das auf die Schnelle richtig gelesen habe --- aber --- die RPG runtime ist natürlich nicht so wirklich für multithreaded geeignet. Thread(*serialize) könnte Klemmer produzieren, bei Thread(*concurrent) gibt's Probleme mit shared Memory (da hat man keinen) und mit der Synchronisation muss man eh alles zu Fuß machen.
Man könnte allerdings auch darüber nachdenken einen eigenen Scheduler auf die Q zu setzen und Workerprozesse selber zu starten und denen den Zustand als globale Sessioninfo (evt. Userspace) zu vererben.

Das mit der PortalApp und den callback Prozeduren hört sich für micht etwas home grown an und das skizzierte Threading ist das auch - warum habt ihr euch hier für soviel Exotik entschieden, ich wäre da näher an den Mainstream gegangen...

Das mit dem X hätte ich fast vergessen, das ändert eigentlich nur, dass der Benutzer früher merkt, dass da was klemmt.

D*B

[bofrost]

... der CHGACGCDE scheint mir nicht das Problem zu sein, der könnte ja im initial thread erfolgen, wenn ich das auf die Schnelle richtig gelesen habe

1. This command is conditionally thread safe. Access will be denied if the job being changed has secondary threads active. This command may be issued from either the initial thread or a secondary thread of a multi-threaded job if the target job is single threaded.

Stimmt, hört sich so an, als dürfte der Job zum Zeitpunkt des Aufrufs nur keine Threads haben.

die RPG runtime ist natürlich nicht so wirklich für multithreaded geeignet. Thread(*serialize) könnte Klemmer produzieren, bei Thread(*concurrent) gibt's Probleme mit shared Memory (da hat man keinen) und mit der Synchronisation muss man eh alles zu Fuß machen.

Naja wenn ich's auf *serialize stell kann ich's gleich lassen, weil dann läuft ja trotzdem alles nacheinander ab. Mit den pthread funktionen und den shared memory Funktionen sollte es doch kein Problem sein die Anwendung multithreading fähig zu machen?

Man könnte allerdings auch darüber nachdenken einen eigenen Scheduler auf die Q zu setzen und Workerprozesse selber zu starten und denen den Zustand als globale Sessioninfo (evt. Userspace) zu vererben.

Hm... gut das wäre dann Threading nachgebaut... dann lieber richtiges threading...

Das mit der PortalApp und den callback Prozeduren hört sich für micht etwas home grown an und das skizzierte Threading ist das auch - warum habt ihr euch hier für soviel Exotik entschieden, ich wäre da näher an den Mainstream gegangen...

Naja wir verwenden am Client ExtJS, hier gibt es ExtDirect Funktionen die einen Zugriff auf den Server erlauben hier wird auch oft mit solchen Callback-Funktionen gearbeitet... Was für Mainstream Lösungen gibt es den in dem Bereich für RPG die empfehlenswert sind?

[BenderD]

Naja wenn ich's auf *serialize stell kann ich's gleich lassen, weil dann läuft ja trotzdem alles nacheinander ab. Mit den pthread funktionen und den shared memory Funktionen sollte es doch kein Problem sein die Anwendung multithreading fähig zu machen?
Hm... gut das wäre dann Threading nachgebaut... dann lieber richtiges threading...

Naja wir verwenden am Client ExtJS, hier gibt es ExtDirect Funktionen die einen Zugriff auf den Server erlauben hier wird auch oft mit solchen Callback-Funktionen gearbeitet... Was für Mainstream Lösungen gibt es den in dem Bereich für RPG die empfehlenswert sind?

RPG und Multithreading, da ist man dann Beta Tester! Ich weiß von niemandem, der das wirklich nutzt und dass es da wirklich Support gibt, bezweifele ich heftigst.

*serialize serialisiert auf Module Ebene, das geht vom Ansatz schon, man muss nur sicher sein, dass man keine rekursiven Modul Aufrufhierarchien bekommt.

*concurrent hat den Haken, dass der komplette static storage für jeden Thread dupliziert wird, da muss man sich was einfallen lassen, damit man doch wieder shared memory hat.

wandelt man einfach ohne eine der beiden Optionen, weß man nicht, welche Kontrollbereiche der runtime ungeschützt im shared memory liegen.

Alternativen zu der ExtJS - RPG Architektur, da fühle ich mich aus dem Bauch überfragt und da ist auch der Informationsstand hier im Forum zu dünn. Was mich gefühlsmäßig stört (und meist stimmt sowas bei mir) ist die Erhöhung des Komplexitätsgrades im RPG Teil im Vergleich zur Altanwendung - und das sollte bei Neudesign unter Verwendung vorhandener Komponenten genau umgekehrt sein.

mfg

Dieter Bender