Die von Fuerchau beschriebene Optimierung beschreibt wie normale SQL-Statement von der AS/400 als preparedStatement erkannt werden - bzw. zumindest wird das von der AS/400 versucht.

In deinem Fall hast du ja bereits prepared Statement.

Da gibt es 2 Vorgangsweisen:

1.) Man erstellt ein prepared Statement (z.B. vor der Schleife) und verwendet dann immer das gleiche Statement (man beschickt nur die Parameter neu).

Der Fehler (*) von den Postings 2005 bestand darin, dass das Statement innerhalb der Verarbeitungsschleife neu erstellt wurde. Mit statement.close() innerhalb der Verarbeitungsschleife funktioniert es zwar - bringt aber nicht so viel.

2.) Man verwendet einen Connectionpool

Damit kann man jedes mal ein neues prepared Statement erzeugen und sofort wieder zumachen. Auch die Verbindung wird nach dem Arbeitschritt geclosed. Beim Connectionpool wird das connection.close() aber als "Connection zurück in den Pool legen" verarbeitet.

Auch wenn man die (prepared) Statements zumacht - bleiben diese auch im Connectionpool.

Damit das so funktioniert muss beim JT400/JTOPEN Pool das lazyclose eingeschalten werden. Bei anderen Connectionspools kann man per Config das offen halten von prepared Statements steuern bzw. die max. offenen Statements angeben.

Man kann das Ganze noch mit Batchupdate ergänzen. Also PreparedStatement.addBatch() sammeln mit mit ..Statement.executeBatch() loslassen.

Bei Massenupdates sollte Autocommit ausgeschalten sein und man sollte z.B. alle 1000 Updates ein COMMIT bzw. executeBatch (bei Batchupdate) machen.

Noch ein Detail am Rande: Wenn man StoredProcedure als prepared Statement offen hält und das 3GL-Programm (CL, Cobol, RPG) mit CALLLVL *CALLER gewandelt ist, bleibt das 3GL offen. Ich bediene z.B. einen Webshop mit kundenspezifischen Preisen. Für einen Preis im GH sind manchmal bis zu 50 Datenbankzugriffen im Bewertungsmodul notwendig. Durch das offen halten des Programmes (Cobol) und dessen Verbindungen geht die Preisermittlung innerhalb von wenigen Millisekunden (zw. 4 - 19 ms).

Durch das switchen der Connections (vom Pool) reicht eine offene Instanz des Bewertunsmoduls aus um bis zu 120 Webkunden damit zu bedienen.

Mit der richtigen Mischung aus RecordLevelAccess und SQL aus Java kann die i5 durchaus mit x86 Systemen mithalten bzw. überflügeln.

/Robert

(*) Den Fehler muss ich ohne Source raten. Aber entweder das oder der JDBC-Treiber hat einen Bug.