Bör man stänga anslutningen i slutet när man använder Connection Pool? Om så är fallet, är inte syftet med poolningen förlorat? Och om inte, hur vet datakällan när en viss instans av anslutning frigörs och kan återanvändas? Jag är lite förvirrad angående den här, alla tips uppskattas.
Ja, definitivt måste du stänga den poolade anslutningen också. Det är faktiskt ett omslag runt själva anslutningen. Den kommer under täcket att släppa den faktiska anslutningen tillbaka till poolen. Det är vidare upp till poolen att avgöra om den faktiska anslutningen ska faktiskt stängas eller återanvändas för en ny getConnection() ringa upp. Så oavsett om du använder en anslutningspool eller inte, bör du alltid stäng alla JDBC-resurser i omvänd ordning i finally block av try block där du har köpt dem. I Java 7 kan detta förenklas ytterligare genom att använda try-with-resources
uttalande.
Är följande metod i närheten av standarden? Ser ut som ett försök att få en anslutning från poolen, och om DataSource inte kan etableras, använd den gammaldags DriverManager. Vi är inte ens säkra på vilken del som körs under körning. Upprepa frågan ovan, ska man stänga anslutningen som kommer ut av en sådan metod?
Exemplet är ganska skrämmande. Du behöver bara slå upp/initiera DataSource endast en gång under programmets start i någon konstruktor/initiering av en programomfattande DB-konfigurationsklass. Ring sedan bara getConnection() på en och samma datakälla under resten av programmets livstid. Inget behov av synkronisering eller nollkontroller.
Se även:
- Är det säkert att använda en statisk java.sql.Connection-instans i ett flertrådat system?
- Använder jag JDBC Connection Pooling?