Wie implementieren andere Firmen ihre SQL-Zugriffe auf die iSeries?

[Pikachu]

Nur sagte der Performance-Berater, dass er das so noch nicht gesehen hätte.

Der scheint wohl noch nicht viel gesehen zu haben.

[Fuerchau]

Nun ja, wenn ihr 1000 Clients habt, so ist es nur klar, dass es auch mindestens 1000 Verbindungen gibt.
Ein ConnectionPool ist natürlich je Client bzw. wie oben beschrieben mit einem ZwischenServer vorhanden.
Wenn ein Client nun mehr als eine Verbindung benötigt so kann es durchaus Sinn machen.
Dies kommt auf die Art der Anwendung an, ob z.b. für Lesen und Update/Insert getrennte Verbindungen verwendet werden.
Dies liegt auch z.B. an der Journalisierung, denn ein Rollback setzt auch einen aktuellen Cursor zurück.
Da ich den Cursor in JDBC/ODBC nicht wie bei embedded SQL in HLL's auf der AS/400 "with hold" deklarieren kann benötige ich in diesem Fall 2 Verbindungen.
Allerdings kann das wiederum entfallen, wenn man mit Resultsets (also vollständig geladenen Daten) und nicht mit dem Reader arbeitet.
Die 2. Verbindung kann ja nach Transaktionsende doch geschlossen werden.
Dies kann man über die "ConnectionPoolSize=1" (oder ähnlich) einstellen.

Jetzt kommt es noch auf die Anmeldesteuerung an.
Steht iSeries-Navigator Verbindungseigenschaften "Immer anmelden" auf ein, so ist jedes mal eine Anmeldung erforderlich, wenn ein Verbindung geöffnet wird und im Programm User/Password weggelassen wird. Dies ist natürlich lässtig.
Aber man sollte ja sowieso mit einem APP-User arbeiten.

Vielleicht kann man den ConnectionPool auch mit einem "Unused Timeout" generieren, so dass nach einiger Zeit die Verbindung geschlossen wird.
Ich habe z.B. in meiner ODBC-Anwendung das System-Pooling abgestellt.
Durch Bereitstellung eines eigenen Connection-Pools wird bei jedem Zugriff auf ein Connection-Objekt ein Timer gestartet. Nach Ablauf des Timers wird die Verbindung dann tatsächlich getrennt.

Auf diese Weise kann ich mitunter mehrere parallele Abfragen (Threading lässt grüßen) durchführen ohne das System nennenswert zu belasten.
Die Wahrscheinlichkeit, dass mehrere Clients dies gleichzeitig tun ist sehr gering.

Die QZDAJOB's auf der AS/400 selber werden auch gepoolt. Wenn also ein Job frei ist, wird dieser auch wieder verwendet bevor ein neuer initiiert wird.

[dschroeder]

Vielen Dank für alle Antworten. Ich werde das alles mit den Java-Kollegen mal besprechen.
Dieter

[KM]

dann brauche ich einen Application Server, der EJBs (Enterprise Java Beans) unterstützt, verbinde meinen Client an diesen EJB Server und der verbindet über einen Connection Pool an die Datenbank meines Vertrauens. Dann kümmert sich der Pool um die Gesundheit der Connections und temporäre Zugriffspfade etc. werden auf Verbindungsebene gecached etc.

Hallo D*B,
auch wenn es jetzt nicht direkt ins AS/400-Forum passt. Aber Du hast die Stichworte Application Server und EJB genannt. Für mich ist das ziemliches Neuland, aber das hört sich interessant an. Bis jetzt hab ich nur mit einem Tomcat-Server gearbeitet, der das bekanntermaßen nicht zur Verfügung stellt. Jetzt habe ich ein wenig nachgelesen, jedoch gibt es ziemlich viele JavaEE Server bzw. EJB-Container, sodass die Auswahl schwer fällt, wenn man sich damit nicht so auskennt.
Gibt es einen bestimmten Server, den Du empfehlen würdest? Was hältst Du z.B. von TomEE, der relativ neu ist und im Prinzip auf den Tomcat aufbaut und ihn um bestimmte Komponenten erweitert?

Gruß,
KM

[BenderD]

... wichtig ist, dass der EJB Container mindestens EJB 3.0 unterstützt und entsprechender Support durch Hersteller oder aktive Community sichergestellt ist (deshalb würde ich immer die Finger von WebSphere auf AS400 lassen). Weiter würde ich die Auswahl immer davon abhängig machen, was ich brauche (nix auf Vorrat installieren, weil das soviel kann). Nach diesen Kriterien ist OpenEJB (der macht den EJB Part in TomEE) schon ein Kandidat.
Der entscheidende Schritt vorher ist allerdings erst mal über die Architektur der Anwendung nachzudenken, sprich: wie soll mein Frontend aussehen, saubere Schichtentrennung...
Die Ausgangsproblematik dieses Threads ist ja gerade mit hoher Wahrscheinlichkeit unzureichende Schichtentrennung und kein Implementierungs technisches Problem.

D*B

[KM]

ok, danke. Dann werde ich mich mal etwas mehr mit OpenEJB bzw. TomEE beschäftigen.

Mein Ziel ist es einfach einen leichtgewichtigen JavaEE-Server zu haben ohne viel Schnickschnack drumherum. Da scheint mir TomEE am geeignetsten zu sein.

Gruß,
KM

[BenderD]

... da ist JBoss auch immer noch eine Option. Die Auswahl des Servers ist aber nicht kritisch, das lässt sich jederzeit mit minimalem Aufwand ändern (Serer installieren, neu deployen), wenn man keine Sonderlocken benutzt, die einem von kommerziellen Varianten (WebsFear & Co.) zuweilen untergejubelt werden.

D*B