Zitat Zitat von Christian.Hesse
.... Es waren PreparedStatements, die nicht geschlossen sind.
Rein vom Speed her, würde ich sie weiterhin offen lassen. Also für die gesamte Klasse deklarieren, aber das Statement nur erzeugen wenn es null ist (Beispielcode) oder dafür einen Schalter machen.

Nachteil: Dateien bleiben geöffnet (aktiver Job bei Sicherungen)
Vorteil: schnellste Lösung

Zitat Zitat von Christian.Hesse
....weswegen ich den Nutzen eines Connection Pools in diesem Fall nicht sehe.
Sehe ich genauso. Einen ConnectionPool brauche ich erst, wenn ICH die Übersicht verliere (WebServer, komplexe GUI und/oder Multithread-Applikationen)...

Zitat Zitat von Christian.Hesse
... In den Applikationen wird zum Schreiben in die Datenbank ein RPG-Programm mit Parametern aufgerufen, welches das Schreiben übernimmt. Angeblich soll das bei der Implementierung deutlich schneller gewesen sein als die Nutzung von Insert/Update per JDBC. Hat da jemand Erfahrungen dazu?
Also unter normalen Umständen, kann ich mir das eigentlich nicht vorstellen. Vielleicht wenn ein Aufruf viele DB-Operationen erzeugt.

Auch bei Updates habe ich, von der Performance her, mit offen gelassenen PreparedStatements gute Erfahrungen gemacht.

Eventuell hilft dieser Thread
bei der Performancesuche etwas.

Bei DB-Updates macht nichtmal unsere kleine Entwicklungsmaschine (170er) mucken.

Robert P.