Insert SQL

[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