Moet men bij gebruik van Connection Pool de Connection aan het einde sluiten? Zo ja, gaat het doel van pooling dan niet verloren? En zo niet, hoe weet de DataSource dan wanneer een bepaald exemplaar van Connection vrijkomt en opnieuw kan worden gebruikt? Ik ben een beetje in de war over deze, alle tips worden op prijs gesteld.
Ja, natuurlijk moet u ook de gepoolde verbinding sluiten. Het is eigenlijk een wikkel rond de eigenlijke verbinding. Het zal onder de afdekkingen de daadwerkelijke verbinding terug naar het zwembad vrijgeven. Het is verder aan de pool om te beslissen of de daadwerkelijke verbinding werkelijk . zal zijn worden gesloten of opnieuw worden gebruikt voor een nieuwe getConnection() telefoongesprek. Dus ongeacht of u een verbindingspool gebruikt of niet, u moet altijd sluit alle JDBC-bronnen in omgekeerde volgorde in de finally blok van de try blok waar je ze hebt gekocht. In Java 7 kan dit verder worden vereenvoudigd door gebruik te maken van try-with-resources
verklaring.
Komt de volgende methode in de buurt van de standaard? Het lijkt op een poging om een verbinding uit de pool te krijgen, en als DataSource niet tot stand kan worden gebracht, gebruik dan de ouderwetse DriverManager. We weten niet eens zeker welk deel tijdens runtime wordt uitgevoerd. De vraag hierboven herhalend, moet men de verbinding sluiten die uit een dergelijke methode voortkomt?
Het voorbeeld is best eng. U hoeft alleen de DataSource . op te zoeken/initialiseren slechts één keer tijdens het opstarten van de toepassing in een constructor / initialisatie van een toepassingsbrede DB-configuratieklasse. Bel dan gewoon getConnection() op één en dezelfde gegevensbron gedurende de rest van de levensduur van de toepassing. Geen synchronisatie of nullchecks nodig.
Zie ook:
- Is het veilig om een statische java.sql.Connection-instantie te gebruiken in een multithreaded systeem?
- Gebruik ik JDBC Connection Pooling?