Nelle prime due parti dell'articolo abbiamo analizzato la teoria alla base del pooling e delle connessioni al DB e l'istanziazione di un DataSource, mentre in questa terza parte se ne vedrà l'effettivo utilizzo.

Prima di usare il pool di connessioni, c'è da considerare un aspetto importante: una web application dovrebbe chiudere sempre esplicitamente i ResultSets, gli Statement e le Connection aperte, perché altrimenti potrebbero essere inutilizzabili per un futuro riuso, causando il cosiddetto connection pool leak, che può portare al fallimento dell’apertura di una nuova connessione, se non dovessero essercene più di disponibili.

In realtà esiste una soluzione che può essere adottata: le Jakarta Commons-DBCP possono essere configurate per tenere traccia e recuperare queste connessioni abbandonate, rendendo possibile anche la generazione di uno stack trace del codice, che ha aperto queste risorse senza chiuderle mai.

La parte fondamentale della configurazione di questo servizio consiste nell’inserirlo nel contesto della web application, nel file server.xml di Tomcat. In particolare nel context dell’applicazione è necessario aggiungere:Analizziamo i principali attributi:

• maxActive: massimo numero di connessioni al DB nel pool, compatibilmente con l’attributo max_connections di MySQL. Il valore 0 indica nessun limite;
• maxIdle: massimo numero di connessioni inattive da mantenere nel pool. Il valore -1 indica nessun limite;
• maxWait: massimo tempo di attesa per la ricezione di una connessione al DB (in secondi) prima del lancio di un’eccezione. Il valore -1 attende senza limiti;
• driverClassName: nome del driver utilizzato per la connessione.
• url: l’URL per la connessione JDBC al DB. Il parametro autoReconnect=true fa sì che il com.mysql.jdbc.Driver si riconnetterà automaticamente se MySQL chiude la connessione, cosa che di default avviene dopo 8 ore di connessione inattiva;
• removeAbandoned="true": fa sì che le connessioni al DB abbandonate siano rimosse e riciclate. Questo vuol dire che quando le connessioni disponibili si stanno esaurendo, DBCP recupererà e riciclerà tutte le connessioni al DB che trova. Il default è false;
• removeAbandonedTimeout="30": serve per settare il numero di secondi che una connessione al DB deve rimanere inattiva prima di essere considerata abbandonata;
• logAbandoned="true": questo attributo può essere settato a true se si vuole che le DBCP generino uno stack trace del codice, che ha abbandonato le connessioni senza chiuderle.

L’ultimo passaggio nella configurazione del servizio è la registrazione della resource nel file web.xml dell'applicazione web:A questo punto il pool di connessioni è definitivamente attivo e sarà possibile utilizzare il DataSource per gestire in maniera efficiente e pulita il DB della web application.

• Pubblicazioni correlate:
• 24-09-2008 Connessioni al database e teoria del pooling (1/3)
• 25-09-2008 Connessioni al database e teoria del pooling (2/3)