Newsgroup: it.comp.java
Titolo: JDBC: Domanda su massimo di connessioni apribili e altro...

Salve,
        come da oggetto, vorrei sapere (non ho trovato riferimenti che mi
soddisfacessero nella documentazione) quante Connection posso aprire
contemporaneamente verso lo stesso DB, e se è adeguato farlo. In
particolare, credo che verso lo stesso DB sia adeguato aprire una sola
Connection, e utilizzare sempre quella. Se due update (quindi due diversi
Statements) che vanno a sovrapporsi, cioè vengono eseguiti
contemporaneamente, se sono in autoCommitt Mode (default), ho un'eccezione o
gli statements vengono accodati ed eseguiti uno dopo l'altro, mantenendo la
consistenza?
Grazie

 consistenza?
La politica di commit/rollback delle transazioni, in autocommit, è delegata
al DBMS, che terrà conto del livello di isolamento delle transazioni stesse.
Per il discorso eccezioni, dipende: se i due update agiscono su due righe
della stessa tabella, assegnando ad entrambe la stessa chiave primaria, la
transazione che termina per ultima subirà un rollback, ma normalmente non si
dovrebbe eseguire applicativamente l'update di una chiave primaria...
Scorpio.

 consistenza?
Parli di due statement inviati dalla *stessa* connessione da due thread 
in concorrenza? E' un errore, il risultato non è prevedibile. E' a 
carico del programma mantenere l'accesso esclusivo del thread alla 
connessione.
Se parli di due statement eseguiti da due diverse connessioni il 
problema non sussiste: se il db gestisce le transazioni puoi non usare 
l'autocommit (anzi...) e ci pensa lui a gestire la situazione, se non 
gestisce le transazioni semplicemente sei costretto ad usare l'autocommit.

Innanzitutto grazie a tutti per le risposte.
Da quanto ho capito, in sostanza, vanno aperte il minor numero possibile di
connessioni perchè occupano risorse (com'è ovvio), ma due statement non
possono agire contemporaneamente (leggi: da due thread diversi) sulla stessa
Connection. Quindi è adeguato, quando si crea ad esempio un'applicazione Web
con delle servlet che accedono a un DB, far sì che ogni servlet abbia la
propria Connection e mettere la servlet in modalità SingleThreadModel. In
questo modo (SingleThreadModel) mai più di un client eseguirà la stessa
servlet (richieste contemporanee verranno accodate), e quindi mai più di uno
statement andrà sulla stessa connessione.
Corretto?
Grazie infinite!

 Corretto?
Nel caso specifico, sincronizzare gli accessi al servlet è eccessivo e 
oneroso. Si può (e si deve) risolvere il problema in altri modi.
[1] la Connection restituita da un DataSource è un decorator della 
implementazione del driver (infatti se vai a vedere la classe non è 
quella del driver) che "modifica" il metodo close() in modo che la 
connessione NON venga chiusa ma restituita al pool. Quindi per la 
programmazione questo aspetto è totalmente trasparente.

 esponi a rischi di perdita di performance...
Sì, ma a quanto ne so con SingleThreadModel il server dovrebbe creare un
pool di oggetti servlet, in numero limitato, e smistare le richieste dei
vari thread tra le servlet del pool... in effetti mi sembra una soluzione
più pulita di mettere direttamente synchronized sui metodi, perchè avrei
comunque possibilità di gestire più client contemporaneamente (anche se non
molti). Se non prevedo enorme traffico, la soluzione è percorribile... o no?
Total

 vari thread tra le servlet del pool...
Questo, sinceramente, non te lo so dire. Io mi ricordavo l'interfaccia
SingleThreadModel non "obbligava" l'application server a gestire un pool di
servlet da assegnare ai client, ma poteva - in application server da poco -
ridursi ad un synchronized globale. Ma non ci giurerei... quello che so, è
che SingleThreadModel è o sarà a breve, deprecato.
Scorpio.

Innanzitutto grazie per le risposte, sei molto gentile.
Dunque, la cosa migliore sarebbe creare in pratica... una connessione per
ogni accesso al DB (non volendo gestire la concorrenza a livello di DB ma a
livello di codice). O meglio, basterebbe una connessione per ogni metodo
(doGet() o doPost(), basta che la connection sia un oggetto locale al
metodo). Ora, oltre al metodo diretto di allocare un oggetto Connection (e
poi ovviamente CHIUDERLO!) in ogni doGet o doPost, che non dà problemi ma
causa comunque un certo dispendio di risorse per l'allocazione ogni volta
della Connection, tu mi suggerisci di usare un pool di connessioni usando un
DataSource, dove la creazione di nuove connessioni e la loro gestione è
gestita dal datasource stesso.
Fin qui ok?
Ora... il datasource è un'interfaccia implementata in modo diverso da ogni
costruttore di DB, dipende quindi dal driver, giusto?
Mi potresti postare un semplice esempio su come creare un datasource con
jdbc:odbc?
Grazie infinite!!!
Total

EJB.Potresti trovarti ad affrontare situazioni spiacevoli....
Potresti approfondire? Le connessioni di un pool fornite da un
datasource, non sono forse "sempre aperte"?

Per creare un pool di connessioni si potrebbe utilizzare la classe messa a
disposizione con la jdk
sun.jdbc.odbc.ee.ConnectionPoolDataSource inizializzata nel seguente modo
private static ConnectionPoolDataSource connectionPoolDataSource=null;
public DBConnection() {
    if(connectionPoolDataSource==null){
        connectionPoolDataSource = new ConnectionPoolDataSource();
        connectionPoolDataSource.setDataSourceName("dataSourceODBC");
        connectionPoolDataSource.setDatabaseName("dataSourceODBC");
        connectionPoolDataSource.setMaintenanceInterval("2000");
        }
}
public Connection getConnection(){
    return  connection=
connectionPoolDataSource.getPooledConnection().getConnection();
}
Ciao Alex

 ha scritto nel messaggio
news:c902b09afhpp26058...@4ax.com...


Ni. Nel senso che in base alle specifiche J2EE, una connessione aperta in un
metodo di una servlet deve essere chiusa (con commit o rollback) entro il
metodo in cui è stata aperta, altrimenti ci pensa il container a chiudere,
eseguendo una commit o rollback in base alle impostazioni di configurazione.
Ma "chiudere" una connessione ottenuta da un connection pool significa,
semplicemente, rilasciarla al pool stesso che la gestirà al meglio,
riallocandola ad altri thread su richiesta degli stessi.
Scorpio.