Newsgroup: it.comp.java
Titolo: Classe DB per ottenere connessioni

Il problema è quello arcinoto di scrivere una classe che gestisca le
connessioni a un DB: gli altri oggetti "chiedono" una connessione e la
ottengono. L'obiettivo è di essere ragionevolmente sicuri che "tutte le
connessioni verranno chiuse".
Come si sviluppa "bene" una classe così, avendo la certezza che "ogni
connessione verrà chiusa"? (Lasciamo per ora stare EJB... che risolverebbe
certamente il problema, diciamo che voglio risolvere la questione con Java2
Standard Ed.).
La classe contiene tutte le variabili di connessione relative al DB (IP,
username, password ecc) e l'inizializzazione del driver JDBC.
Ovviamente la sviluppo con un singleton, in modo da essere sicuro di
inizializzare la connessione al DB (leggi: la stringa di inizializzazione
JDBC) una e una sola volta. Poi un metodo mi crea un nuovo oggetto
connessione e lo passa. Chi lo ottiene avrà cura di chiuderlo.
Per esempio:
final class DBWrapper
{
    private boolean initialized;
    private static DBWrapper db = new DBWrapper();
    private DBWrapper()
    {
        try
        {
            DriverManager.registerDriver( .... );
            initialized=true;
        }
        catch (SQLException se)
        {
            ...
        }
    }
    public static DBWrapper getReference()
    {
        return db;
    }
    public Connection getConnection()
        throws SQLException
    {
        return DriverManager.getConnection(...);
    }
}
L'oggetto utilizzatore farà:
DBWrapper db = DBWrapper.getReference();
Connection conn = db.getConnection();
[usa la connessione per agire sul db]
conn.close();
La suddetta architettura vi convince? Se sì, o se no, perché? (PS: come
potrebbe essere scritta la classe perché la chiamata di chiusura della
connessione venga "automaticamente" invocata?)
Alessio.

La chiusura della connessione deve avvenire dopo che ci hai fatto tutte le
operazioni del caso. L'unica cosa che mi viene in mente e di usare una
callback.
Invece di creare questa classe solo per avere connessioni, ci metti un metodo
del tipo :
void run(DBCallBack client) {
    CREA LA CONNESSIONE
    //eleabora
    client.execute(...);
   CHIUDE LA CONNESSIONE
}
Chi usa il wrapper non conosce niente della connessione, ma ne userà una
appropriata (magari passata nel prototipo di execute) e alla fine il wrapper
chiude la connessione.


 connessione venga "automaticamente" invocata?)
In C++ ci sono i distruttori di una classe che vengono invocati
immediatamente
ogni volta che l'istanza di tale classe esce dal suo scope. In tale
linguaggio
sicuramente la strada giusta sarebbe quella di incapsulare l'oggetto
connection
in una classe wrapper e mettere nel suo distruttore un conn.close(). Poi
obbligare l'utente a creare sempre una nuova classe wrapper ogni volta che
ne ha bisogno localmente (magari creando una classe Factory che gestisca
eventualmente anche un pool di connessioni). E' una tecnica che ho gia'
utilizzato con successo diverse volte.
Il fatto e' che in Java non esistono, o perlomeno esiste qualcosa del genere
che e' il finalize. Tale metodo pero' e' eseguito in maniera asincrona dal
garbage collector (in pratica non si sa' esattamente quando verra' invocato)
e questo e' sicuramente un problema.
Io ho risolto il tutto creandomi una mia classe personalizzata (che tra
l'altro
gestisce anche un pool di connessioni) ed introducendo il concetto di
timeout. In pratica ho un Thread a bassa priorità che monitorizza le
mie connessioni, e quando queste rimangono inutilizzate oltre al timeout
indicato vengono chiuse automaticamente.
Fino ad ora non ho avuto problemi (tieni presente che pero' sono stato
abbastanza attento ogniqualvolta la utilizzavo a chiuderla subito dopo,
gestendo anche degli oppurtuni blocchi finally {} ).
In caso di eccezioni anomale (piu' che altro simulate manualmente per
adesso) ho comunque riscontrato che dopo un certo periodo la
connessione veniva chiusa (intanto le altre connessioni che fanno parte
del pool allo stesso database continuano a funzionare).
Sono cmq dell'avviso che la soluzione alla C++ sarebbe molto piu'
pulita.
Ciao.
Nicola

 connessioni verranno chiuse".
Mi spiace di deluderti ma queste cose ci sono gia'!!!!!!!!
http://java.sun.com/products/jdbc/articles/package2.html
Vedi Connection Pooling
Saluton

 > ottengono. L'obiettivo č di essere ragionevolmente sicuri che "tutte le


 wrote in message
news:9d6ilq$pqo$1...@fe2.cs.interbusiness.it...


 sua in quel momento sua figlia s'è messa a piangere...)
In effetti la devi vedere nel contesto di un'applicazione Web con la
relativa gestione di un Pool di connessioni. In pratica quello che tu
dici non si potrebbe mai verificare (a patto che l'esecuzione di una
servlet duri meno del timeout della connessione che solitamente
lo imposto molto alto) perche' l'utente ad ogni richiesta che fa' sul
browser utilizza sempre una connessione diversa (che appartiene al
pool). Questo vuol dire che se la connessione precedente non si e'
chiusa correttamente quella connessione non verra' piu' utilizzata da
nessuna procedura finche non verra' liberata dal Thread in questione.
Sono dell'avviso che comunque il metodo migliore e' sempre quello di
chiudere
le connessioni nei classici blocchi finally {} (che in fondo sevono proprio
a quello) subito averle utilizzate.
Ciao.
Nik

 pace. 
Questa e' buona che centra il connection pool con EJB????????
Come dire: non uso jndi altrimenti userei EJB.
Mah

 wrote in message news:9d8lei$v0un$1...@news01.it.net...
