Insert SQL

[RobertPic]

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.

[Fuerchau]

@Robert
Das Verhalten betrifft alle SQL-Zugriffe, also auch die per ODBC/DRDA.
Wenn man eine Verbindung mit Debugmode öffnet, kann man entsprechende Hinweise auch im Joblog finden.

Ausserddem übertrage ich mit Dieter Benders Java-Transfer-Beispielen auch jede Menge Daten zwischen AS/400 und Oracle in beide Richtungen.
Ich verwende auch für den Insert prepared Statements.
Selbst nach 100.000 Inserts habe ich obigen Fehler noch nicht erhalten.

[RobertPic]

@Robert
Das Verhalten betrifft alle SQL-Zugriffe, also auch die per ODBC/DRDA.
Wenn man eine Verbindung mit Debugmode öffnet, kann man entsprechende Hinweise auch im Joblog finden.

Jein. Nur beim ersten Aufruf! Der Witz soll ja sein, dass das prepared Statement wiederverwendet wird. Das heißt das Statement bleibt offen (man sieht im ODBC-Job auch die offene Datei) und sollte (laut Java Theorie) auch keinen Syntaxcheck mehr durchlaufen.

Ausserddem übertrage ich mit Dieter Benders Java-Transfer-Beispielen auch jede Menge Daten zwischen AS/400 und Oracle in beide Richtungen.
Ich verwende auch für den Insert prepared Statements.
Selbst nach 100.000 Inserts habe ich obigen Fehler noch nicht erhalten.

Dieter Bender's Programm fragt auch brav ab, ob es das prepared Statement bereits gibt - es wird nur 1x erzeugt, offen gelassen und mehrmals verwendet.

if(out == null) {
   prepare();
}
out.execute();
...
void prepare() {
try {
   insert = props.getString("insert");
   out = con.prepareStatement(insert);
..

Genau diese Abfrage (out == null) fehlt(e) offensichtlich bei den Threadstellern. Damit wird jedesmal ein neues Statement erzeugt. Das Close innerhalb der Verarbeitungschleife ist da der falsche Lösungsweg. Das hat Ottersberg schon richtig erkannt.

/Robert

[BenderD]

- manchmal ist der Unterschied zwischen Loesung und zweitbester gering (if (ps == null))
- am besten ist hier natuerlich immer ein Connectionpool, der was taugt (eben nicht aus der Dollschachtel!)
- extended Package Support bringt meist fast nix und ist bei einigen Treiberversionen katastrophal (Bug !?)
- wenn die Hardware stimmt, dann brauchts den (oft abenteuerlichen) Mix aus Java und 1,86 GL nicht

D*B

[RobertPic]

- extended Package Support bringt meist fast nix und ist bei einigen Treiberversionen katastrophal (Bug !?)

Yep. I zitiere noch von der IBM Websphere FAQ:

In our opinion, the extendedDynamic/packageCache provides you no additional advantage when used with Application Server connection pooling and statement cache.

Sollte man wohl abschalten.

- wenn die Hardware stimmt, dann brauchts den (oft abenteuerlichen) Mix aus Java und 1,86 GL nicht

1.) Die Hardware ist nicht immer das Problem. Der 3GL/Javamix ist nicht immer freiwillig. Nur weil es mit Java schöner geht, kann ich ja trotzdem nicht über Nacht Code von zig Mannjahren in Java neuschreiben. Ich finde die stored Procedures noch die am wenigsten abenteuerliche Methode 3GL-Funktionen in Javaapplikationen zu nutzen.

2.) Wollte ich einmal die Performance der DB2 auf der AS/400 loben. Wenn man noch mit andere Datenbanken (spez. Oracle) arbeitet, kommt dieser Wunsch nicht oft vor..

/Robert

[BenderD]

die Datenbanken haben wohl unterschiedliche Charakteristik, DB2/400 ist kein Rennpferd, aber relativ gutmütig, wie Ackergäule halt sind. Was die Performance angeht ist DB2/400 nicht so schlecht, wenn man genug Hardware und parallel Database Feature hat (und die von manchen heiß geliebte SQE nict dazwischen bugt) und die Satzanzahlen unter 500 Millionen liegt, aber da wird die Luft acuh für andere dünn...

D*B

2.) Wollte ich einmal die Performance der DB2 auf der AS/400 loben. Wenn man noch mit andere Datenbanken (spez. Oracle) arbeitet, kommt dieser Wunsch nicht oft vor..

/Robert