Yocker
  1. Yocker
  3. Quando chiudere Connection, Statement, PreparedStatement e ResultSet in JDBC
Intereting Posts
Offset riga in SQL Server Qual è la differenza tra django OneToOneField e ForeignKey? Il tag del datalist HTML5 non viene popolato in Safari L’espressione ___ è cambiata dopo che è stata verificata Java’s BigDecimal.power (esponente BigDecimal): Esiste una libreria Java che lo fa? Inizializzazione di array in java Coordinate geospaziali e distanza in chilometri Risolvi le classi senza registrarle utilizzando Castle Windsor Scarica un database mysql in un backup in formato testo (CSV) dalla riga di comando Come ottenere il nodo XML da XDocument L’aggiunta non funziona in JavaScript Posso chiamare una vista da un’altra vista? Estensione Chrome: come salvare un file su disco È ansible replicare il valore numerico automatico di Swifts ponticellato su Foundation (NSNumber) per i tipi (U) Int8 / 16/32/64? Android Studio: completamento automatico e altre funzionalità non funzionanti

Quando chiudere Connection, Statement, PreparedStatement e ResultSet in JDBC

Poche domande sulla codifica JDBC:

  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 mia connessione non viene chiusa dopo ogni query, perché non mantenere vivo il 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 sola volta e riutilizzato molte volte statement? 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,

Personalmente userei un pool in quanto questo si prenderà cura di tutta la gestione delle risorse per voi. Se i requisiti di connessione cambiano, è ansible modificare facilmente la configurazione del pool. Con una piscina sul posto è ansible aprire / chiudere connessioni e istruzioni preparate secondo le migliori pratiche e lasciare la gestione delle risorse al pool.

In genere, quando si utilizza un pool:

  • chiudere una connessione in realtà lo restituirà alla piscina
  • l’atto di preparare una dichiarazione o recupererà un’istruzione precedentemente preparata dalla cache dell’istruzione di Connection, oppure 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à semplicemente 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 rendono più facile identificare questo tipo di problemi nel codice.

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

1. Anche se si dispone di un singolo client, un pool di connessioni potrebbe comunque essere utile. 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 connessioni simultanee che di solito non è un numero elevato. 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.