Disconnect nach Backup DTAQ

[BenderD]

Hallo,

grundsätzlich würde ich mich bei DataQ Objekten nicht auf korrekte Funktion im Multithreading verlassen wollen!!! Deshalb hatte ich auch stored Procedures genannt, was sicherlich Auswirkungen auf die Architektur der Lösung gehabt hätte.

Die Hypothese mit der Sicherung ist für mich noch schwach, da scheint mir ducrchaus noch Klärungsbedarf - und wenn der Kunde den nicht sieht und gleichzeitig Vorgaben macht, dann muss er wohl mit den Konsequenzen leben.

mfg

Dieter Bender

Hallo zusammen,

Vorgabe ist, DataQueues zu nutzen. Die werden vom Kunden zur Verfügung gestellt.
Deshalb kann ich auch keine StoredProcedures einsetzen. Übrigens würde das nicht nur durch laufendes Polling und Aufrufen der Proc das gleiche Verhalten wie eine DataQue ermöglichen?

Wir versuchen gerade das Ganze zu entzerren und bauen für den lesenden Zugriff einen Dienst, der dann nach einem Timeout neu gestartet wird. Das ist dann die harte Variante, unschön aber funktioniert dann halt.

Leider lehnt der Kunde es ab, einfach eine Shutdown Message in die Queue zu schreiben. Das wäre meiner Meinung nach noch das schönste. Dann könnte ich nach diesem Read den Thread regulär beenden. Da aber noch Dritte an der Schnittstelle hängen möchte man sich wohl Abstimmungen sparen.

Wie genau das "Abhängen" unseres Dienstes auf AS/400 Seite funktioniert ist mir nicht klar und wir haben da auch keine Einsicht.

Eine Frage habe ich noch: Kann es sein, dass es Probleme gibt, wenn man in einem Thread im Read() steht und gleichzeitig aus einem anderen Thread einen Write() durchführen will? Beide Queues nutzen das gleiche AS400 Objekt.

Ich bin mir sicher, dass das Write richtig durchläuft, aber der Kunde sagt, er bekommt keine Daten auf AS400 Seite.

Übrigens bin ich sehr überrascht, über die netten Antworten! Danke!

Louis Haußknecht

[ParkerLouis]

Ist es denn legitim, in einem Prozess mehrere AS400 Objekte aufzumachen, die sich dann auch alle an der Maschine anmelden? Klingt ja nicht richtig resourcensparend, aber wir brauchen einen gangbaren Weg dafür.

[BenderD]

ich kann das immer nur aus der Java Perspektive beantworten: jedes DataQ Objekt repräsentiert einen Server Job, der immer nur eine Anforderung nach der anderen verarbeitet; ein Lese Thread mit einem langen Wait braucht also eine eigene Connection, wenn man das vermeiden will, müsste man auf Socket Verbiondungen umsteigen (was nicht zur Anforderung passt). Optimieren kann man die Mehrfach Verbindungen durch einen Pool (was Java angeht, taugen die von der Toolbox nix).

Ist es denn legitim, in einem Prozess mehrere AS400 Objekte aufzumachen, die sich dann auch alle an der Maschine anmelden? Klingt ja nicht richtig resourcensparend, aber wir brauchen einen gangbaren Weg dafür.

[ParkerLouis]

Okay, ich sehe schon. Beim nächsten Projekt wird Java für die direkte SChnittstelle zur AS/400 genommen. Da gibt es deutlich mehr Resourcen für im Netz.

Die jetzigen Probleme werde ich dann durch Trennung der Prozesse (und ggf. Neustart des lesenden Prozesses) und einer Connection pro Queue umbauen.

Vielen Dank für Eure Hilfe,

ich werde noch mal berichten, wie das System weiter läuft.

Louis

[Fuerchau]

Eine Connection zur AS/400 kann nur 1 Aktion zu 1 Zeit durchführen.
Wenn du also parallel zum Read mit Timeout einen Write benötigst, muss das auch über eine eigene Connection durchgeführt werden.
Eigentlich sollte der Write sogar mit einem Fehler abgewiesen werden.

Für die korrekte Synchronisation sorgt die AS/400 (klappt ja auch mit RPG/CLP u.a.).

Mit Java hat das nix zu tun, da du auch hier die Toolbox nehmen musst.

Wichtig ist halt nur zu erkennen, wann die Verbindung tatsächlich unterbrochen wird.
Das kann man auch schon mal mit ziehen des LAN's (trennen Lan-Verbindung) simulieren, was ja auch schon mal vorkommt.

[BenderD]

ad RPG/CL: klappt nur, weil RPG/CL Programme weder connecten dürfen (die APIs laufen synchron im eigenen Job), noch üblicherweise mehrere Threads haben. Vor V6 wurde das garnicht unterstützt und ab V6 geht da richtig der Punk ab, wenn man mit C_API spawn Threads erzeugt.

ad Fehler: die Implementierung dürfte single threaded sein, mehrere Aufrufe werden schnöderweise in eine Q eingereiht und verhungern dann gegebenen Falls alle gemeinsam.

ad Java: da gibt es Object Pools und ähnliches in hoher Qualität als Open Source

mfg

Dieter Bender

Eine Connection zur AS/400 kann nur 1 Aktion zu 1 Zeit durchführen.
Wenn du also parallel zum Read mit Timeout einen Write benötigst, muss das auch über eine eigene Connection durchgeführt werden.
Eigentlich sollte der Write sogar mit einem Fehler abgewiesen werden.

Für die korrekte Synchronisation sorgt die AS/400 (klappt ja auch mit RPG/CLP u.a.).

Mit Java hat das nix zu tun, da du auch hier die Toolbox nehmen musst.

Wichtig ist halt nur zu erkennen, wann die Verbindung tatsächlich unterbrochen wird.
Das kann man auch schon mal mit ziehen des LAN's (trennen Lan-Verbindung) simulieren, was ja auch schon mal vorkommt.