quando chiudere Connection, Statement, PreparedStatement e ResultSet in JDBC

Question

alcune domande su JDBC codifica:

1. Per una singola applicazione client, abbiamo bisogno di un pool di connessione?
2. È una buona idea creare una connessione all'inizio e mantenerla in vita senza chiuderla fino all'uscita dall'applicazione? Perché?
3. PreparedStatement è associato a Connection, se la connessione non viene chiusa dopo ogni query, perché non mantenere vivo PreparedStatement e riutilizzarlo in altri metodi?
4. se creiamo PreparedStatement ogni query, il database sa che è lo stesso PreparedStaement e ignora le azioni non necessarie dopo la prima volta?
5. PreparedStatement non viene creato una volta e riutilizzato più volte istruzione? se sì, perché è necessario chiuderlo ogni volta?

So che la chiamata a close() rilascerà la risorsa. Ma se sappiamo che lo useremo in seguito, perché rilasciarlo e poi richiederlo più tardi?

Che ne dici dell'applicazione multi-client? abbiamo bisogno di un pool di connessioni e quindi dobbiamo creare e chiudere Connection, Statement e PreparedStatement ogni volta?

grazie,

Answer 1

Personalmente userei una piscina come questo si prenderà cura di tutte le gestione delle risorse per voi. Se i requisiti di connessione cambiano, è possibile modificare facilmente la configurazione del pool. Con un pool sul posto è possibile aprire/chiudere connessioni e istruzioni preparate in base allo best-practice e lasciare la gestione delle risorse al pool.

In genere, quando si utilizza un pool:

• chiusura di una connessione sarà in realtà solo restituirlo al pool
• l'atto di preparare una dichiarazione sarà o recuperare una dichiarazione preparata in precedenza dalla cache dichiarazione del collegamento, o se uno non è disponibile, crea una nuova istruzione e memorizzala nella cache per utilizzarla in un secondo momento.
• l'atto di chiudere un PreparedStatement in realtà lo restituirà alla cache dell'istruzione della connessione.

Inoltre, a seconda dell'implementazione del pool, potrebbe essere in grado di notificare quando ci sono perdite di risorse che facilitano l'identificazione di questo tipo di problemi nel codice.

Dai un'occhiata all'origine di un'implementazione di esempio come DBCP - è piuttosto interessante vedere come funzionano.

Answer 2

1. Anche se si dispone di un singolo client, un pool di connessioni potrebbe comunque essere vantaggioso. La connessione al database potrebbe richiedere molto tempo, pertanto fare molto spesso potrebbe rallentare l'applicazione con richieste di rete lente. Inoltre, come spiega @teabot, un pool può aiutare a identificare se una connessione non viene chiusa.

2. Non è una buona idea aprire una connessione e lasciarla aperta per sempre per due motivi. Per prima cosa la connessione potrebbe morire se si verifica un'interruzione temporanea della rete. Più a lungo è aperto più è probabile che sia morto quando richiesto.In secondo luogo, una transazione fallita può lasciare la connessione in uno stato non adatto per continuare l'operazione. Di solito è meglio aprire alcune connessioni, riutilizzarle per cinque o dieci minuti, quindi riciclarle.

3. A seconda del database e del driver, la connessione potrebbe disporre di una cache di istruzioni preparata. Anche se si utilizza una connessione diversa, l'RDBMS solitamente memorizza nella cache le istruzioni che sono esattamente uguali, inclusi i parametri. Quindi SELECT * FROM table WHERE value =? come una dichiarazione preparata verrà memorizzata nella cache attraverso le connessioni, ma se si specifica il valore del parametro come SELECT * FROM tabella WHERE value = 'your_data' allora probabilmente non verrà memorizzato nella cache lato server.

4. Come spiegato in 3, dipende dall'implementazione RDBMS, fare un punto di riferimento.

5. Non è necessario chiudere e preparare nuovamente una dichiarazione che verrà riutilizzata con parametri diversi. Basta impostare nuovamente i parametri ed eseguire.

Per più client, il database avrà sempre un limite di connessione simultanea che di solito non è un numero grande. Se tutti i client passano attraverso una webapp, allora un pool come DBCP va bene. Ma ovviamente non è auspicabile creare un pool per ogni cliente con diverse connessioni aperte in modo permanente.