Hallo,

das mit dem Connection Pool...
Hauptvorteile sind:
- einfacheres Transaktionshandling (pro Transaktion eigene Connection vom Pool)
- Zentralisierung des Connection Handlings (ab und an schließen und neue öffen, wg. vergammeln etc.)
- gute Pools können prepared Statements cross Connection poolen
Primär geht es um Design und erst sekundär um Performance!!!

Zur Performance von updates: bei read Write Logik ist es meist vorteilhaft positioned updates über ResultSet zu machen statt searched updates

Ansonsten geht im allgemeinen messen (DBMON) über raten.

mfg

Dieter Bender


Zitat Zitat von Christian.Hesse
Hallo RobertPic,

du hast recht: Es waren PreparedStatements, die nicht geschlossen sind. Vielen herzlichen Dank.

Die Rückgabe der Verbindungen an einen Connection Pool wird derzeit nur beim Application Server genutzt, da die "Clients", die mir momentan mit das größte Kopfzerbrechen bereiten 24/7 connected sind und SQL-Statements ausführen. Diese bestehen aus einer Verbindung von einer Java-Anwendung, die alleine auf einem Rechner untergebracht ist, weswegen ich den Nutzen eines Connection Pools in diesem Fall nicht sehe.

Da fällt mir aber noch etwas anderes ein: 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?

Ich werde mal versuchen, meinen Problemen weiter auf den Grund zu gehen - vielleicht findet sich noch irgendetwas, was ich bisher übersehen habe.

In diesem Sinne nocheinmal herzlichen Dank allen und bis bald!

Gruß

Christian