DBCP: Verbindungen schließen: ja oder nein?

[public_void_main]

Hallo,

in einem aktuellen Projekt verwende ich eine "nackte" Apache DBCP / JDBC-Implementierung ohne einen Applikationsserver.
Für mich geht aus der DBCP-Dokumentation an keiner Stelle hervor, ob sich das Framework auch selbständig um den Abbau von Datenbankverbindungen kümmert oder ob dies in meiner Verantwortung liegt. Es gibt einige Methode, mit denen man Limits für die Anzahl von "idle connections" festlegen kann, ebenso wie eine initiale Größe des Pools.
Aber nirgendwo wird wirklich beschrieben, ob ich mich tatsächlich um die Verbindungsabbau kümmern muss oder nicht. Die Art der Dokumentation liebe ich an vielen Apache-Projekten...

Könnt ihr mir mit Euren Erfahrungen hierbei weiterhelfen?

Ich kann mir vorstellen, dass es reichlich imperformant ist, nach jedem SQL-(Prepared)Statement die Verbindung abzubauen und danach wieder zu öffnen. Das ist ja nicht Sinn der Sache. Andererseits ist es sonst kaum möglich zu kontrollieren, wann Verbindungen wieder abzubauen sind. Das soll ja eigentlich auch DBCP für mich lösen (hoffe ich).

Geschätzt werden ca. 250-500 parallele Verbindungen zum Datenbankserver erwartet.

Vielen Dank!

 

[Niki]

Wenn du eine Connection aus dem Pool holst (über den DataSource...) bekommst du einen Proxy zurück. Wenn du auf diesem Proxy dann close aufrufst, wird die Connection wieder in den Pool zurück gelegt. (Ich hoffe das stimmt so)

 

[maki]

250-500 Parallele Verbindungen???

Klingt imho nach sehr viel....

Nebenbei, wie sollte man sich als Client um Verbindungsabbau kümmern können, dass macht doch der Pool, dafür ist er ja da.
IMHO werden die meisten Verbindungen durch einen Timeout "abgebaut"...

 

[public_void_main]

@maki - ja, bis 500 Verbindungen, das ist ein mittelgroßes Projekt... deswegen ja unbedingt DBCP.

Ist Dein letzter Satz eine Vermutung? Ich fänd's schön etwas handfestere Angaben zu kriegen. Grundsätzlich bin ich ja auch der Meinungen, dass DBCP sich um das Pooling und damit um den Verbindungsabbau kümmert -- aber beschrieben wird das auf der Apache-Projektseite (mal wieder) nicht.

 

[Niki]

Das Abbauen der Verbindungen macht auf alle Fälle der Pool, die Frage ist nur wann. Entweder wie maki sagte durch Timeouts, oder wenn die Applikation geschlossen wird (eventuell über Shutdown-Hook)
Du musst dich nur darum kümmern dass die Verbindungen wieder in den Pool zurück gelegt werden (Connection#close)

//EDIT
Weil du meintest 500 Verbindungen. Das sind aber nicht die Anzahl der verbundenen Clients, oder? Du brauchst nicht für jeden Client eine eigene Verbindung. Sobald eine Transaktion gestartet wird sollte eine Verbindung aus dem Pool geholt werden, dann wird die Transaktion gestartet, mit commit/rollback beendet und die Verbindung in den Pool zurück gelegt. Die Transaktionen/Connections sollten eben nur so kurz wie möglich gehalten werden

 

[maki]

Vermutung?
Klar, aber wie sollten sie sonst geschlossen werden?
Ich sehe keinen Sinn darin, einen Pool zu verwenden, wenn ich die Verbindungen selbst schliessen muss.

In meinen mittelgroßen Projekten hatte ich max. 30 Verbindungen, aber dass muss ja nichts heissen.
Darf man fragen wie du auf diese Zahl kommst?
Bei so vielen Verbindungen würde ich nicht notwendigerweise DBCP verwenden, gibt auch andere CPs.

Auf der anderen Seite arbeite ich immer mit einem ConnectionPool sobald ich JDBC nutzen muss (was gott sei dank selten geworden ist).
Mit Frameworks wie iBatis oder gar ORM wie Hibernate ist ein Pool auch ein muss, leicht zu konfigurieren über die Frameworks.

 

[public_void_main]

Niki - danke für die Infos!
TimeOuts wären für mich OK. Shutdown-Hooks kann ich hier leider nicht implementieren.
Was ich nun noch nicht ganz verstanden habe, ist Dein Satz danach:
Du musst dich nur darum kümmern dass die Verbindungen wieder in den Pool zurück gelegt werden (Connection#close) ---> Das wäre dann in dem Fall eines Shutdown-Hooks zu machen, habe ich das richtig verstanden?

Zum Verständnis: Für mich ist es dasselbe, die Verbindung zu schließen oder sie in den Pool zurückzugeben. Wichtig wäre demnach dann (bitte nochmal konkret sagen) zu wissen, ob tatsächlich so etwas wie

preparedStatement.execute();
connection.close();

in meinem Code auftreten muss. Dass die Verbindung danach vom DBCP ins Pool gelegt wird ist mir klar. Nicht aber, ob ich selbst die Verbindung explizit schließen muss.



Zu den 500 Verbindungen: Es handelt es sich um 500 Clients, das ist richtig. Ich bin davon ausgegangen, dass sie gleichzeitig auf dem System arbeiten und daher jeder tatsächlich eine eigene Connection benötigt. Es können auch 250 Clients sein, die parallel zugreifen. Aber der Richtwert liegt im Hunderterbereich.

 

[Niki]

Es ist nicht das selbe ob du die Connection zurück legst oder abbaust. Du musst nachdem Absetzten des Statements connection.close aufrufen, das close schließt aber in diesem Fall die Verbindung nicht, sondern legt sie in den Pool zurück. Du solltest dich auch nicht um den Abbau der Verbindungen kümmern, das macht alles der Pool. Nur eben wann ist die Frage. Entweder bei Timeouts, oder beim Beenden der Applikation. Das hat dich aber eigentlich gar nicht zu kümmern. Für dich ist nur wichtig dass du die Verbindung mittels close zurück gibst.
Für 500 gleichzeitige Benutzer reichern wahrscheinlich 50 - 100 Verbindungen allemal, da ja nicht jeder Benutzer gleichzeitig eine Transaktion starten wird. Normalerweise kann ma einen Pool auch so konfigurieren dass er neue Connections erzeugt, sobald er sie benötigt oder die Threads müssen warten, bis eine Connection wieder frei gegeben wird.

 

[public_void_main]

Alles klar, das hat meine Frage beantwortet. Vielen Dank.

 

[maki]

Ich würde so maximal 30-50 Verbindungen verwenden.

1 User = 1 Verbindung ist schlecht gerechnet, und kostet mehr als es bringt.