Når man bruger Connection Pool, skal man så lukke forbindelsen til sidst? Hvis ja, er formålet med at samle så ikke tabt? Og hvis ikke, hvordan ved datakilden, hvornår en bestemt forekomst af forbindelse er frigivet og kan genbruges? Jeg er lidt forvirret over denne, alle tips er værdsat.
Ja, du skal helt sikkert også lukke den samlede forbindelse. Det er faktisk en indpakning omkring selve forbindelsen. Det vil under lågene frigive selve forbindelsen tilbage til poolen. Det er yderligere op til puljen at beslutte, om den faktiske forbindelse faktisk vil lukkes eller genbruges til en ny getConnection() opkald. Så uanset om du bruger en forbindelsespulje eller ej, bør du altid luk alle JDBC-ressourcerne i omvendt rækkefølge i finally blok af try blokere, hvor du har erhvervet dem. I Java 7 kan dette forenkles yderligere ved at bruge try-with-resources
erklæring.
Er følgende metode tæt på standarden? Det ligner et forsøg på at få en forbindelse fra poolen, og hvis DataSource ikke kan etableres, så brug den gammeldags DriverManager. Vi er ikke engang sikre på, hvilken del der bliver udført under kørsel. Ved at gentage spørgsmålet ovenfor, skal man lukke den forbindelse, der kommer ud af en sådan metode?
Eksemplet er ret skræmmende. Du skal bare slå op/initialisere DataSource kun én gang under applikationens opstart i en eller anden konstruktør/initialisering af en applikationsdækkende DB-konfigurationsklasse. Kald derefter getConnection() på den ene og samme datakilde gennem resten af applikationens levetid. Intet behov for synkronisering eller nullchecks.
Se også:
- Er det sikkert at bruge en statisk java.sql.Connection-instans i et multithreaded-system?
- Bruger jeg JDBC Connection Pooling?