Java-Datenbank-Treiber JT400 unter V6R1

[hartmuth]

Danke für die wertvollen Hinweise.
Ich hatte beim Wechsel auf V5R4 sogar mit einem QMQRY einen extremen Fall, wo eine Auswertung plötzlich mehr als die doppelte Zeit beanspruchte.

Hoffentlich gibt es keine Probleme mit jener Anwendung, wo die Statements vom OR-Mapper Hibernate erzeugt werden. Da hätte ich nämlich keinen Einfluss darauf.
Das andere sollte in den Griff zu bekommen sein.
Ein wenig "Bauchweh" bereiten die vielen UDFs, die aber leider notwendig sind, um die notwendigen Daten zu erhalten.

[andreaspr@aon.at]

SP und UDFs sollten nach einem Releasewechsel generell neu erstellt werden.
Der Grund ist die Performance. Mit jedem Release können mehr Anweisungen in C-Code konvertiert werden.
Speziell Vergleichsoperationen und Wertzuweisungen könnten im neuen Release besser verarbeitet werden. (Wenn sie neu erstellt werden)

lg Andreas

[RobertPic]

Wir haben unsere Systeme mit V5R4 gegen neue i7 mit V7R1 ausgetauscht. Wir haben zahlreiche Javaapplikationen (meistens Tomcat) - aber die Treiber nicht extra aktualisert. Das ging soweit ohne problemlos.

Probleme mit nicht aktuellen JDBC-Treibern sind nicht ganz auszuschließen - aber eher die Ausnahme bei der AS/400 (da kenne ich schlimmeres z.B. Oracle).

Das Problem, dass manche Statements je nach Release unterschiedlich performen, hält sich bei der AS/400 auch in Grenzen.

Probleme hatten wir nur mit ein paar QM-Queries und erst jetzt mit dem letzten DB2 PTF Group (SF99701 #11) . Hier erzeugte die Paginglogik von Hibernate einen internen SQL-Systemfehler....

Noch zur Performance (viele Änderungen DB-Engine kamen schon mit V6R1):
Während die SQL-Eingine bei V5R4 teilweise eine "Verschlimmbesserung" war, hat mich V7R1 bislang überzeugt.

Während die nativen Cobol/RPG-Programme "nur" um den Faktor 3-4 schneller wurden, konnte ich bei SQL-Procedures/Selects, Steigerungen im Bereich Faktor 5-10 ausmachen.
(Anmerkung: wir benchmarken und protokollieren Anfragen aus dem Webshop).