Nelle applicazioni J2EE, l'istanziazione di connessioni verso il DB viene spesso considerata impropria se realizzata brutalmente da codice, mentre si ritiene più pulito o preferibile l'utilizzo di un un pool di connessioni verso il database, sotto forma di JDBC DataSource, fornito dal container (Tomcat, Jetty, WebLogic).

Il container è responsabile di mantenere un numero di connessione verso il database e tutto il nostro codice, per ottenere una connessione deve solo fare il lookup del DataSource tramite JNDI.

Molte applicazioni web necessitano di accedere al database attraverso un driver JDBC per supportare le funzionalità offerte dall’applicazione. Tomcat 5 offre esattamente lo stesso supporto degli application server della J2EE, in modo che applicazioni basate su connessioni al database sviluppate su Tomcat, usando il servizio di DataSource gireranno senza alcuna modifica su qualsiasi server J2EE.


Prima di introdurre la gestione degli accessi al DB, è bene specificare il concetto di pool di connessioni, elemento cardine del funzionamento della maggior parte dei DataSource. Il pooling è una maniera di gestire le risorse, che sono costose da creare e in costante richiesta, ma usate soltanto per un breve periodo di tempo. La maggior parte degli sviluppatori Java è familiare con i pool di connessioni al database, o almeno con pool di thread.

Il pooling si basa su un principio molto semplice: invece di instanziare direttamente una risorsa per la connessione, il codice noleggia una risorsa da un repository centralizzato. Il codice client usa la risorsa e la restituisce al repository. Quest'ultimo è responsabile del ciclo di vita degli oggetti risorsa, cioè istanzia un certo numero di oggetti risorsa e li rende disponibili per la fruizione e successivamente li reinizializza.

Il pool è esaurito quando tutte le risorse sono occupate ed è cura dell'implementazione del pool gestire la richiesta in caso di esaurimento di risorse: l'operazione può essere bloccante (ovvero non ritorna) finché una risorsa è disponibile, ritornare null o lanciare un'eccezione.

I classici problemi di connessione ai DB si riassumono nel rischio di timeout, dovuti ad attese prolungate (spesso legati a rallentamenti della rete o a basse velocità di trasferimento); esso è pericoloso perché non permette la corretta gestione delle risorse, che sono state aperte, o la possibilità che un numero troppo elevato di utenti (rispetto alle connessioni possibili) possa accedere alla stessa applicazione web in contemporanea.

Programmatori, anche molto esperti, utilizzano spesso escamotage che, a fronte della risoluzione di problemi semplici, generano criticità ben più gravi o decadimento di prestazioni: tipico esempio è l'istanziazione di connessioni brevissime che eseguono attività elementari. Pur ovviando ai suddetti rischi, questa soluzione comporta un enorme rallentamento dell'intera applicazione poiché la chiusura ed il ripristino di ciascuna connessione costa, in termini di tempo, molto più della maggior parte delle altre attività.

La proposta di utilizzare i DataSource, invece, può garantire efficienza, pulizia di codice e minimizzazione dei rischi. Tale soluzione sarà analizzata in dettaglio nelle successive parti di questo contributo.