Newsgroup: it.comp.java
Titolo: Caricare il driver JDBC adatto

Salve, sulla documentazione delle API della libreria di java alla pagina di 
"java.sql.DriveManager" c'è una nota alle prime righe che dice di utilizzare 
la classe DataSource per connettersi ad una sorgente di dati;
anche ad un database?
Poi dice che le applicazioni non hanno più bisogno di caricare il driver con 
"Class.forname(...)" e la chiamata a getConnection() cerca di trovare un 
driver disponibile per stabilire la connessione.
Allora se non c'è bisogno di usare Class.forname() come devo fare a caricare 
il driver giusto per stabilire la connessione col database?
Grazie.
 

 caricare il driver giusto per stabilire la connessione col database?
il driver "giusto" lo stabilisci nella stringa di connessione.
la chiamata a Class.forName() serviva a forzare il caricamento in 
memoria della classe driver, perchè altrimenti non era disponibile. 
adesso invece è sufficiente che il driver sia nel classpath perchè sia 
disponibile.
-- 
Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com

 Grazie.
Stiamo parlando di J2EE ? In tal caso, fai una lookup del datasource, il 
driver
lo scegli a priori quando configuri il datasource. Se stiamo parlando di 
J2SE, una
volta caricati i driver è l'url di connessione che consente al driver 
manager di
stabilire il "suitable driver" per quella connessione.
Scorpio.

 writes:
S> Stiamo parlando di J2EE ?
No, č la standard edition, package java.sql e javax.sql.
Il  meccanismo  del  DriverManager  č  stato sostituito  da  quello  dei
DataSource, in pratica scaricando completamente il barile sui produttori
di database  :), che comunque  Sun non puň  scrivere driver per  tutti i
database del pianeta... MySql potrebbe avere ottimi driver sotto Java :)
:) :).
Tra l'altro č interessante vedere l'implementazione di DriverManager di
Sun a confronto con quella di IBM, hanno delle simpatiche differrenze.
Se tutto va bene quella di IBM offre tempi di risposta migliori, in caso
di casini (i.e. un database Oracle con una SGA di 3GB ed un prodotto che
richiede alla  C.D.C.  la prepaged SGA)  l'implementazione piů conserva-
trice di Sun risulta vincente.
-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                   e coltivatore diretto               not install
                               di software                   Debian"
a Cesare avrei detto di scrivermi | I would have told Caesar to write
a 
fn...@rat.vg
                    | me at 
fn...@rat.vg

 trice di Sun risulta vincente.
boh, questa non l'ho capita.
ne ibm ne sun hanno una implementazione del driver di oracle.
se ti vuoi connettere ad oracle devi scaricare il jdbc dal sito della 
oracle, sia che usi il DataSource sia che tu ci vada direttamente.


> più conserva- trice di Sun risulta vincente.
r> boh, questa non l'ho capita.
Si vede  che non  l'hai capita. Si  vede da  lontano che non  hai capito
molto del post :)
Perdona la cattiveria,  è bonaria, non vera. E poi me  la hai servita su
un piatto d'argento!
r> ne ibm ne sun hanno una implementazione
r> del driver di oracle.  se ti vuoi connettere ad oracle devi scaricare
r> il jdbc dal sito della oracle, sia che usi il DataSource sia che tu
r> ci vada direttamente.
Ti vai a vedere i sorgenti di java.sql.DriverManager e capisci tutto :).
Tutti i metodi dell'implementazione Sun sono sincronizzati, e la lista
dei driver è,  mi pare, in una Hashtable.
L'implementazione di IBM è... quella di Sun, solo che: hanno tolto tutti
i syncronized dai metodi ed hanno tenuto la sincronizzazone sull'oggetto
Class solo  per le parti  in cui una  certa richiesta di  connessione si
clona la sua  copia della tavola dei driver  installati (hanno una copia
in scrittura da  cui clonano una copia in  lettura ad ogni aggiornamento
della copia in scrittura - registrazione di un driver - e poi la clonano
nel momento in cui viene richiesta una connessione).
Cosa succede quando arrivano N thread a fare N connessioni:
- Nella implementazione di Sun i thread si mettono in coda, e ciascun
  thread riesce a fare due connessioni in rapida successione.
  L'N-esimo thread avrà un tempo di risposta che è la somma dei tempi di
  risposta  per il  suo servizio  e  per tutti  i servizi  che lo  hanno
  preceduto.
- Nella implementazione  di IBM i  thread vanno avanti come  una allegra
  orda,  scaricando   tutta  l'eventuale  sincronizzazione   sui  driver
  fisici. Usualmente  un singolo thread ha  un tempo di  servizio un po'
  più alto, ma globalmente risponde più velocemente.
Quando ci  si trova che il DB  ha 3Giga di SGA  "prepaged", almeno sotto
Linux, ad ogni connessione il  DB deve garantire che ogni processo abbia
le sue  pagine di  SGA belle e  pronte, aggirando  la lazy-copy-on-write
(credo si chiami così) del sistema.
Risultato, all'aumentare del numero  di connessioni in parallelo i tempi
di  servizio   della  singola  esecuzione  crescono  a   tal  punto  che
l'implementazione  di IBM arriva  a perdere  su quella  di Sun  anche 10
secondi  con  30 thread  con  2 connessioni  ciascuno, in questo caso la
politica conservatrice di Sun vince (in produzione si toglie la prepaged
sga e si prepara una Vergine di Norimberga per chi provi a riproporla).


 molto del post :)
anche dopo la spiegazione non è cambiato granchè, ma va bene così. 
quello che volevo chiarire l'ho chiarito.


 in quella di IBM) e ti chiarirai un po' le idee.
ti ho risposto con i sorgenti davanti.


> che in quella di IBM) e ti chiarirai un po' le idee.
r> ti ho risposto con i sorgenti davanti.
In questo caso...


 Se non ci arrivi :)...
no, non ci arrivo. semplicemente perchè non vedo la differenza, in
questo contesto, fra un tomcat che gira nella jvm sun e uno che gira
nella jvm ibm (situazione che, fra l'altro, ho in manutenzione).

 writes:
r> hai detto bene, se lo sai.  nelle implementazioni j2ee non lo sai
r> perchč fa abbastanza comodo non saperlo.  quando definisci un
r> DataSource con jboss, ad esempio, usi la sua implementazione del
r> DataSource e la configuri per il database che piů gradisci.
E  a quel  punto nel  DataSource SAI  (perché č  scritto  nella configu-
razione) che driver devi usare. Ergo, che cavolo ti serve passare per un
DriverManager per fare una connessione ?
L'unica spiegazione alla presenza di un DriverManager in un DataSource č
che il codice č vecchio :).
-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                   e coltivatore diretto               not install
                               di software                   Debian"
a Cesare avrei detto di scrivermi | I would have told Caesar to write
