Java e i database. Che cosa sono i database?

Transcript

1 2001 proprietà di MokaByte s.r.l. tutti i diritti riservati è vietata la riproduzione non autorizzata anche parziale Java e i database DI NICOLA VENDITTI Che cosa sono i database? Ogni giorno nel mondo vengono scambiati inimmaginabili volumi di dati e quasi in ogni parte del mondo le informazioni vengono recuperate, elaborate, trasformate, accresciute, aggiornate e infine re-immagazzinate. Questa enormità, che è una novità della nostra epoca, rappresenta, per la sua portata, un raggiungimento per il genere umano. I databases sono il centro vitale di questo movimento: ci permettono non solamente di archiviare i dati e le informazioni raccolte nei vari campi della nostra attività economica, scientifica ecc., ma ci garantiscono anche la sicurezza e l integrità dei dati medesimi, così come la possibilità di poterli recuperare in ogni momento nel modo più efficiente e rapido possibile. A mano a mano che l informatica ha conquistato un ruolo fondamentale nei vari campi dell attività umana, è emersa la necessità di avere dei sistemi capaci di gestire in modo avanzato i dati e le informazioni. I DBMS (DataBase Management System) sono la risposta più significativa a questa esigenza. Per DBMS si intende un sistema costituito essenzialmente dal database vero e proprio e, soprattutto, dal software per gestire tutte le operazioni che ordinariamente si fanno su un database, dall archiviazione all aggiornamento, fino al backup, al mirroring e così via. Risale agli inizi degli anni Ottanta la comparsa sul mercato software dei primi DBMS e si trattava per lo più di sistemi che usavano il file system del sistema operativo che li ospitava come repository dei dati e delle librerie C per accedere ad essi da parte dei programmi client. Pioniere nel campo della ricerca orientata ai database è stata la IBM che, prima ancora di altri grandi database vendor come Oracle e Informix, si trovò ad affrontare la necessità di fornire sui propri sistemi mainframe, allora già largamente diffusi, del software capace di gestire l archiviazione dei dati. Come detto, originariamente, e in parte anche adesso, era il file che veniva utilizzato come unità di storage per i database. Così la ricerca si orientò allo studio di un metodo di organizzazione e strutturazione dello spazio nei files per un archiviazione ottimale e un accesso efficiente ai dati. Un risultato tuttora popolare di questa ricerca fu l ISAM (Indexed Sequential Access Method). 1

2 Il concetto di tabella divenne popolare insieme al modello relazionale agli inizi degli anni Settanta grazie a Codd (un ricercatore di IBM), che gettò le basi di un approccio teorico ancora largamente utilizzato in questo settore. Con la comparsa di nuovi protagonisti nel campo dei database, sorse l esigenza di avere un linguaggio comune per l accesso ai dati, visto che ognuno disponeva di una propria libreria (ad esempio Informix nelle primissime versioni del suo database forniva una libreria detta C- ISAM ). Anche in questo la IBM fu protagonista, e finì per diffondersi un suo linguaggio chiamato SQL (Structured Query Language) oggi molto popolare: da allora non ha subito modifiche ma solo aggiunte. L SQL, derivato a sua volta da un altro linguaggio sperimentale chiamato SEQUEL (da qui la diffusa pronuncia siquel ) creato per un sistema che si chiamava System R. La standardizzazione dell SQL voluta da ISO e ANSI risale al Una successiva standardizzazione, nel 1992, introduce nuovi e interessanti elementi senza cambiare la struttura. A questa versione dell SQL si ci riferisce come SQL-92. Prima di passare al punto di vista client, e quindi a Java e JDBC, ecco una breve panoramica dei tipi di database esistenti sul mercato. Il modo più comune per classificare i database è quello di discriminarli in base al modello di organizzazione dei dati che utilizzano al loro interno. Usando questo metodo una possibile suddivisione dei databases potrebbe essere quella che segue nei prossimi paragrafi. Relazionali Si basano sul modello relazionale: prevedono quindi organizzazione dei dati concettualmente descrivibile in termini di entità e relazioni tra di loro; l accesso e la manipolazione dei dati viene fatto tramite SQL. Esempi: Oracle 8i, Informix Dynamic Server.2000, DB2 e altri. Dimensionali Sono una specializzazione dei primi: per il datawarehouse: utilizzano il modello relazionale ma i princìpi con cui viene definito il modello di un db dimensionale è diverso da quello tradizionale basato sul concetto di normalizzazione. Per accedere e utilizzare le caratteristiche di questi database si utilizza una versione estesa dell SQL. Questi database vengono più comunemente chiamati OLAP (On Line Analytical Processing) per confronto con i precedenti anche conosciuti con il nome di OLTP (On Line Transaction Processing). Esempi: Redbrick, Informix XPS e altri. Object Oriented Sono molto più recenti dei primi due. Più che basi di dati sono framework per la persistenza di oggetti applicativi. Non vi si accede con l SQL; il modello di accesso ai dati non differisce dai meccanismi che il linguaggio OO (per cui il database fornisce il binding) utilizza per la creazione e la gestione degli oggetti. 2

3 Esempi: UniData di Ardent, Jasmine di CA. Object Relational Rappresentano una via di mezzo tra i database relazionali puri e i database OO anche se più esattamente possono essere considerati dei relazionali con estensioni di supporto per la tecnologia Object Oriented. Per accedere a questi database si utilizza ancora l SQL, ed è lo stesso SQL, attraverso alcune estensioni proprietarie a permettere l accesso alle caratteristiche a oggetti di questi database. Accesso ai database: il punto di vista applicativo Parallelamente all evoluzione dei database sono cambiati i meccanismi con cui le applicazioni accedono ai dati. Originariamente come detto ogni DBMS disponeva, per le applicazioni, di proprie librerie C. Oltre all SQL fu creato uno standard a livello di chiamata detto appunto Call Level Interface (CLI) proposto da X/Open. Fu cioè definita la sequenza di chiamate che l applicazione (per lo più un applicazione C) doveva seguire per accedere in modo corretto alle informazioni. I produttori di database hanno iniziato a fornire questo set di librerie in aggiunta alle proprie originarie. Per esempio ancora adesso il database Oracle fornisce uno strato CLI detto OCI (Oracle Call-level Interface). JDBC è modello anch esso basato sullo standard CLI per l accesso alle basi di dati. Il gruppo responsabile di Java ha deciso, a ragione, di fornire il proprio linguaggio di una propria libreria per le operazioni sui dati. Le motivazioni sono diverse ma si capisce subito che una libreria scritta per il C difficilmente si adatta a un linguaggio basato su classi e interfacce (e, per giunta, a differenza del C++, privo di puntatori). Il risultato raggiunto brilla sicuramente per semplicità ed essenzialità: con solamente 4 righe di codice posso caricare il driver più adatto alla base di dati che voglio interrogare, ottenere la connessione, creare lo statement e recuperare il result set esplicitando la query. I problemi che occorre affrontare quando si scrive una libreria per l accesso ai database sono diversi e non solo di tipo applicativo: si deve garantire dal lato client una coerenza logica il più possibile vicina alla filosofia del linguaggio che l applicazione usa, adattandosi ai metodi tra loro molto differenti che i DBMS utilizzano per processare le richieste dei client; si deve fornire poi una specifica per la scrittura e l implementazione dei drivers e non da ultimo convincere i produttori di database della opportunità di scrivere drivers per questa nuova interfaccia. Pertanto il risultato di semplicità e universalità di JDBC è tanto più apprezzabile. JDBC è una interfaccia a oggetti per l esecuzione di comandi SQL: è bene sottolineare quindi che il linguaggio SQL rimane il vero medium per la comunicazione con il database e lo stesso vale per le altre tecnologie a oggetti concorrenti di Java come DAO. Ciò è dovuto al fatto 3

4 che i database con cui si comunica sono per lo più relazionali e non sono predisposti per supportare le moderne applicazioni a oggetti. L accesso ai dati può essere considerata un anomalia nel paradigma Object Oriented alle radici di Java e del C++ ad esempio, dove non esiste il concetto di dato semplice né tantomeno quello di riga e di tabella. Per questi linguaggi occorrerebbe, più che una repository di dati come i database tradizionali, un framework per la persistenza degli oggetti: tutto quello che l applicazione dovrebbe fare sarebbe solo di indicare un astratta repository da cui recuperare un oggetto che rappresenta un certo elemento di realtà e in cui immagazzinare o più precisamente rendere persistenti gli oggetti nel loro stato applicativo. Si può però ovviare in vari modi a ciò e Java permette di utilizzare diverse tecniche per farlo (p.e. usando un layer software intermedio basato su RMI). A parte questo problema, JDBC è molto flessibile, anche grazie al fatto che è stato progettato basandosi sul concetto di interfaccia e non di oggetto: tutte le operazioni necessarie per accedere ai dati vengono fatte attraverso i metodi esposti da interfacce (che il driver JDBC si occupa di implementare) e non occorre istanziare alcun oggetto. Introduzione a JDBC Spiegare come è fatto JDBC significa essenzialmente dire come una applicazione deve utilizzarlo, perché in fondo non è altro che una libreria per applicazioni Java. Per accedere alla funzionalità di JDBC occorre che l applicazione importi il package java.sql, parte integrante di tutte le Virtual Machine a partire dalla versione 1.1. Al momento la versione più recente di JDBC è la 2.1, che comprende tutto il JDBC 1.1 e lo estende con nuove funzionalità e in più le Standard Extensions introdotte per l integrazione di JDBC nella piattaforma J2EE; vedremo più avanti le novità introdotte con JDBC 2.0 e cosa sono le Standard Extensions, per adesso concentriamoci sul core di JDBC. Come detto JDBC è progettato sul modello CLI. Esso fornisce oggetti e metodi per l interazione con un qualunque DB. Prima di vedere, con l ausilio di alcuni esempi, come funziona, vediamo brevemente una tipica applicazione. Supponiamo di disporre di un DB per il quale esista un driver JDBC. I passi da compiere per l esecuzione di una semplice query sono principalmente i seguenti: 1. Caricamento driver JDBC e connessione al DB Prima di ogni cosa occorre caricare il driver che gestisce la nostra base dati in modo esplicito o implicito. Ecco un esempio di caricamento esplicito della classe di un driver: Class.forName("com.informix.jdbc.IfxDriver"); per caricare il driver JDBC tipo 4 di Informix. La seconda operazione da fare è la connessione al DB individuato univocamente dalla stringa o URL di connessione. Al termine di questa operazione si dispone di un oggetto di tipo Connection che rappresenta la connessione. 4

5 Per la connessione l applicazione si affida al Driver Manager; l applicazione semplicemente richiede una connessione specificando l URL del database a cui desidera connettersi. Connection conn = DriverManager.getConnection("jdbc:oracle:thin:@ORCL:1025", "scott", "tiger"); Sarà il Driver Manager a recuperare il driver giusto attraverso un meccanismo a cui devono conformarsi tutti i driver JDBC. Una volta selezionato, il driver sarà responsabile di tutte le operazioni per quella connessione. 2. Creazione dello Statement object Creata la connessione al DB si è in possesso di un oggetto che rappresenta la connessione al DB. Da esso è possibile poi ottenere tre diversi tipi di oggetti che permettono di creare SQL query da inviare al DB. Questi sono Statement, PreparedStatement e Callable Statement. Essi differiscono per le modalità con cui sono eseguite all interno del DBMS. Alcuni DBMS potrebbero non avere tutte e tre le implementazioni dal punto di vista nativo. Ecco il frammento di codice che recupera lo statement Statement stmt = conn.createstatement(); Come vedremo, si possono recuperare versioni più specializzate per lavorare per esempio con le stored procedure; l esempio sopra riportato è però sufficiente a dare l idea. 3. Esecuzione della query Una volta creato uno dei tre oggetti precedenti non ci resta altro che eseguire la query. Le specifiche JDBC vogliono che le operazioni avvengano in modo thread safe in maniera tale che oggetti diversi accedano agli stessi dati in modo sicuro. Ecco un esempio ResultSet rs = stmt.executequery("select * FROM utenti"); 4. Elaborazione dei risultati Come vedremo una volta eseguite le query si ottiene un oggetto di tipo ResultSet che contiene i dati risultati della query ordinati per record. Attraverso il suo metodo next() è possibile percorrere tali record e accedere ai campi dello stesso attraverso opportuni metodi getxxx. Come detto all inizio, quando si costruisce una libreria per i database occorre che questa si conformi al modello di accesso ai dati utilizzato del medesimo. Questo è un esempio evidente. In questo caso sembra che abbiate a vostra disposizione un oggetto che contiene al suo interno il set di dati recuperato ma non è così. In realtà la query (è sottinteso che stiamo parlando di una query ) ha solo creato un cursore che punta inizialmente alla prima riga del set di risultati ritornati: il metodo next() serve per spostare il cursore in avanti e i metodi getxxx() si utilizzano per spostare effettivamente i dati dal server al client. 5

6 Per rendervene conto potete utilizzare il seguente drastico esperimento: provate ad eseguire i passi fino al 4 e, dopo la prima chiamata a next(), provate a distruggere la tabella su cui è stata fatta la query. Se non vi fossero i cursori e l applicazione avesse tutti i risultati della query, allora potrebbe scandire il suo result set anche se la tabella originaria non esiste più, e invece viene segnalato un errore grave. Ritorneremo su questa differenza quando parleremo dei RowSets. Il metodo standard per la scansione dei risultati è mostrato nel codice che segue. while(rs.next()) { String nome = rs.getstring(1); // colonna 1 contiene il nome String cognome = rs.getstring(2); // colonna 2 contiene il cognome int eta = rs.getint(2); // colonna 3 contiene l'età 5. Eventuale commit e rollback JDBC offre la possibilità di gestione delle transazioni. Per inciso, il database a cui si connette l applicazione deve supportare le transazioni. Ciò si traduce nel fatto che nel database dell applicazione deve essere abilitato il log delle operazioni. Verificate presso l amministratore del DB che sia effettivamente così. Se il logging sul database non è abilitato, e quindi non sono supportate le transazioni, riceverete un esplicito messaggio di errore in tal senso. La commit o la rollback della transazione vanno invocate attraverso gli omonimi metodi dell oggetto Connection. 6. Rilascio delle risorse utilizzate Una volta eseguite le operazioni volute è bene rilasciare le risorse acquisite per cui si chiude la connessione al DBMS. Ciò comporta per lo meno la chiusura degli oggetti ResultSet, Statement e Connection, nell ordine inverso alla loro apertura. Se occorre, avete a disposizione un metodo su tali oggetti per verificare se l operazione è già stata effettuata: isclose(), che però vi dice solo che il metodo close() sull oggetto è stato già chiamato, e non se la connessione è attiva o meno. Ecco tradotta in un piccolo esempio di programma che utilizza JDBC su ODBC, la sequenza di passi appena illustrata. try { // Caricamento esplicito del driver JDBC per il tipo di sorgente // di dati che mi interessa: in questo caso una fonte ODBC Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); // Creazione della connessione al database (tramite // il Driver Manager) Connection con = DriverManager.getConnection("jdbc:odbc:MokaDb"); // Creazione dello statement, l'oggetto che utilizzo per // spedire i comandi SQL al database Statement st = con.createstatement(); // Eseguo la query o un altro comando SQL attraverso lo statement // e recupero i risultati attraverso l'interfaccia ResultSet 6

7 ResultSet rs = st.executequery("select * from lettori"); // Scandisco il result set per la visualizzazione // delle informazioni recuperate while (rs.next()){ System.out.println("Nome: " + rs.getstring(1)); System.out.println("Cognome: " + rs.getstring(2)); System.out.println("Telefono: " + rs.getstring(3)); System.out.println(" " + rs.getstring(4)); System.out.println("Categoria: " + rs.getstring(5)); System.out.println(" "); // Rilascio le risorse utilizzate rs.close(); // result set st.close(); // statement con.close(); // connessione catch(classnotfoundexception cnfe) { System.err.println("Attenzione classe non trovata" + cnfe.getmessage()); catch(sqlexception sqle) { System.err.println("Attenzione errore SQL" + sqle.getmessage()); Fino ad ora abbiamo mostrato la sequenza di passi da seguire per l esecuzione di una query. Ovviamente JDBC permette di eseguire tutte le operazioni SQL di manipolazione dei dati e delle strutture dati (comandi DDL e DML). Prima di affrontare nel dettaglio tutte le possibilità di JDBC soffermiamoci su alcuni aspetti generali di JDBC. Convenzioni JDBC URL Naming Per permettere a una applicazione di accedere a un database, la prima cosa da fare è definire la localizzazione dello stesso e la modalità di accesso, come ad esempio il tipo di driver da utilizzare oppure UserID e Password dell utente con il quale si intende accedere ai dati. Tutte queste informazioni devono essere rese disponibili al momento della connessione in un qualche formato prestabilito. La soluzione scelta consiste nell impacchettare tutti questi dati in una stringa, detta di connessione, che viene utilizzata al momento della creazione del collegamento. Per la scelta della sintassi di tale stringa si è adottato un formalismo derivante da quello utilizzato per la definizione degli URL. La struttura generica di tale stringa è la seguente: jdbc:<subprotocol><domain-name> Nella sintassi URL il primo termine indica il protocollo da utilizzare per la gestione della risorsa individuata, e che in questo è ovviamente jdbc. Il subprotocol rappresenta invece il sottoprotocollo ovvero il driver che si intende utilizzare come interfaccia al DB verso il DBMS. Per domain-name si intende, invece, il nome della risorsa che verrà elaborata dal driver in relazione a delle regole caratteristiche del driver stes- 7

8 so. Nel caso più comune di utilizzo del bridge jdbc-odbc, un URL potrebbe essere il seguente: jdbc:odbc:// In questo modo si indica che la risorsa che vogliamo raggiungere attraverso JDBC e il driver bridged JDBC-ODBC, si chiama dblettori. Come detto l interpretazione del domainname dipende dal driver. Nel caso del bridge il nome dblettori rappresenta il nome di un DSN (Data Source Name). Nel seguente caso jdbc:infonaming:db si interpreterà il nome db in relazione a quello stabilito dal sottoprotocollo infonaming che potrebbe, ad esempio, indirizzare al DBMS in un URL caratteristico dello stesso. Gestione dei driver: il DriverManager Come si può dedurre dalle considerazioni fatte, i driver assumono un ruolo fondamentale. Ad essi è delegato il compito di adattare tutte le operazioni possibili con JDBC al DBMS corrispondente. JDBC dà la possibilità di collegarsi a diversi DB individuati da diversi URL. Serve quindi un meccanismo per associare a ciascun sottoprotocollo il driver corrispondente. A questo compito è dedicata la classe java.sql.drivermanager. Essa gestisce i driver e permette di stabilire una connessione con il DBMS indirizzato fornendo un oggetto di tipo java.sql.connection rappresentativo della connessione. Il meccanismo di caricamento del driver corrispondente all URL può avvenire in due modi: attraverso la lista dei driver elencati nella proprietà di sistema jdbc.drivers. I vari driver disponibili saranno scritti in relazione alla proprietà jdbc.drivers, in successione divisi dai due punti ( : ). Quando si cerca, attraverso il metodo getconnection() di stabilire una connessione al DB e quindi di ottenere un oggetto Connection, il Driver- Manager carica tutti i driver elencati nella proprietà di sistema jdbc.drivers. Poi registrerà i driver trovati attraverso il metodo registerdriver(). Per stabilire la connessione, il DriverManager farà un parsing dell URL e cercherà il driver corrispondente tra quelli memorizzati. Possiamo ottenere la lista di questi attraverso il metodo getdrivers(). 8

9 richiamando esplicitamente il driver attraverso la istruzione Class.forName(). In questo caso si avrà il caricamento del driver e la gestione dello stesso come se fosse avvenuta nel modo descritto al punto precedente. Nell esempio che segue è riportata una porzione di codice completa che partendo dalle due modalità di caricamento del driver, esegue alcune semplici operazioni, come la connessione e il successivo controllo sui driver disponibili. if (loadtype.compareto("esp")==0) { // Caricamento del driver per mezzo del settaggio // della proprietà di sistema sql.drivers System.out.println("Caricamento implicito del Bridge JDBC-ODBC"); Properties prop = System.getProperties(); prop.put("jdbc.drivers", "sun.jdbc.odbc.jdbcodbcdriver"); System.setProperties(prop); else { //caricamento del driver per dichiazione esplicita try { System.out.println("Caricamento esplicito di JDBC-ODBC"); Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); catch(classnotfoundexception cnfe) { System.out.println("Attenzione: driver non disponibile"); // controllo di tutti i driver caricati Enumeration enum = DriverManager.getDrivers(); System.out.println(""); System.out.println("Elenco dei driver disponibili in memoria"); System.out.println(" "); System.out.println("Driver =" + enum.nextelement()); while (enum.hasmoreelements()) System.out.println("Driver" + enum.nextelement()); La classe DriverManager non è l unica che permette di stabilire una connessione al DB. Esiste anche l implementazione dell interfaccia Driver. Essa contiene tutte le informazioni relative a un particolare driver. È possibile conoscere se esso è JDBC-Compliant, la sua versione, se accetta oppure no un determinato URL. Attraverso il metodo connect() è possibile creare la connessione a un URL. Questa interfaccia è utile nel caso di gestione avanzata di determinati Driver in quanto permette, attraverso un oggetto Properties di assegnare valori a suoi eventuali parametri. A tale scopo è dedicata anche la classe DriverPropertyInfo. Ecco un esempio di utilizzazione dell interfaccia Driver per conoscere le caratteristiche del database. try { // caricamento del driver per dichiazione esplicita Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); 9

10 catch(classnotfoundexception cnfe) { System.out.println("Attenzione il driver non è disponibile"); try { Enumeration drivers = DriverManager.getDrivers(); while (drivers.hasmoreelements()) { Driver driver = (Driver) (drivers.nextelement()); System.out.println("Driver: " + driver); System.out.println("Accetta standard jdbc-url: " + driver.acceptsurl("jdbc:odbc:mokadb")); System.out.println("Minor Version: " + driver.getminorversion()); System.out.println("Major Version: " + driver.getmajorversion()); System.out.println("JDBC Compatibile:" + driver.jdbccompliant()); Gestione degli errori Si sono visti fino ad adesso tutti i modi per poter gestire i dati contenuti in un database per mezzo delle librerie JDBC. Più avanti sarà approfondita le differenze che ci sono nel caso si debba realizzare una applet o una applicazione. Per il momento è bene prendere in considerazione un aspetto abbastanza importante, quello della gestione delle eccezioni durante questo tipo di operazioni. Le SQLExceptions Negli esempi riportati precedentemente, si è potuto osservare che ogni volta che viene eseguita una operazione delicata, viene intercettata una eccezione di tipo SQLException. Questa classe offre una serie di informazioni relativamente al tipo di errore che si è verificato. Essa deriva dalla più generale java.lang.exception, la quale a sua volta deriva dalla Throwable. Le informazioni contenute nella classe sono le seguenti: il tipo di errore verificato sotto forma di una stringa descrittiva; tale informazione può essere utilizzato come Exception message e può essere ricavata per mezzo del metodo getmessage(). una proprietà (SQLState) descrivente l errore in base alle convenzioni dello standard X/Open SQLState. Può essere ottenuto con getsqlstate(). un codice di errore specifico del produttore del database, e che in genere corrisponde al messaggio di errore fornito dal DBMS stesso; geterrorcode() permette la sua lettura. una catena al successivo oggetto di tipo SQLException, la quale può essere utilizzata se si sono verificati più di un errore. Il metodo getnextexception() permette di spostarsi su questa catena. 10

11 Nell esempio che segue è mostrato come utilizzare tali informazioni per avere una descrizione completa dell errore verificatosi. try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection con = DriverManager.getConnection("jdbc:odbc:MokaDb"); Statement st = con.createstatement(); //esegue una istruzione errata: la tabella Lettrici non esiste ResultSet rs = st.executequery("select * from Lettrici"); catch(classnotfoundexception cnfe) { System.out.println("Classe non trovata" + cnfe.getmessage()); catch(sqlexception sqle) { System.out.println("Attenzione errore SQL" + "\n"); while (sqle!= null) { System.out.println("Messaggio SQL \n" + sqle.getmessage() + "\n"); System.out.println("SQLState \n" + sqle.getsqlstate() + "\n"); System.out.println("Codice errore del produttore \n" + sqle.geterrorcode()+ "\n"); System.out.println("Traccia dello StackTrace"); sqle.printstacktrace(system.out); sqle = sqle.getnextexception(); System.out.println(""); I Warnings Oltre alle eccezioni alle quali si è abituati in Java, nel caso specifico di JDBC è disponibile anche un altro strumento per la gestione delle situazioni anomale. La differenza che sussiste fra un Warning e una eccezione è essenzialmente nel fatto che il primo non interrompe il flusso del programma: si dice infatti che sono dei segnalatori silenziosi di anomalie. Un Warning viene scatenato direttamente dal database, in funzione del tipo di errore che si verifica. Non è possibile generalizzare quando l uno o l altro tipo di strumento viene generato, essendo molto dipendente dall implementazione del db. I Warning offrono lo stesso tipo di informazioni delle eccezioni SQLException, e possono essere ricavate con metodi del tutto identici rispetto al caso precedente. I metadati JDBC permette quello che la documentazione di Sun chiama accesso dinamico ai database. Il nome non indica molto, ma si tratta della possibilità di accedere a un database e ricavarne informazioni sulla sua struttura interna (tabelle, relazioni, sinonimi, link, trigger, ecc.) senza saperne nulla a priori. In questo modo posso, per esempio, interrogare una tabella utenti senza sapere esattamente quali e quante sono le colonne che la compongono. La risposta è nel fatto che tutti i DBMS hanno delle tabelle interne dette dizionari che contengono metainformazioni circa la struttura interna dai database. Per fare un esempio, quando si crea un database Informix, prima ancora che vengano create tabelle dagli utenti abilitati, ne viene automaticamente creata qualche decina come normale processo di creazione del database. Se si hanno i privilegi e si esegue il comando "SELECT * FROM systables" si 11

12 può aver l elenco di tali tabelle che hanno nomi a volte molto espliciti (sysindexes, systriggers, syscolumns, ecc.). JDBC sfrutta questa possibilità e fornisce un paio di interfacce per fornire al programmatore un modo per accedere a tali meta-informazioni. Chiudiamo questa panoramica su JDBC con una applicazione completa che può essere utilizzata per eseguire query su database Cloudscape. Cloudscape è il database della omonima software house recentemente aquisita da Informix, distribuito in evaluation dalla Sun con la propria piattaforma Java 2 Enterprise Edition. Per provare il programma quindi potete utilizzare l installazione di J2EE che avete sulla vostra macchina oppure scaricare una versione gratuita di Cloudscape per valutazione. Cloudscape può anche essere utilizzato come database di test per le tecnologie J2EE che agiscono su Data Sources, pertanto è comodo un programma da linea di comando per l esecuzione di queries come il seguente. package esempi.cloudscape; import java.sql.*; /** * Semplice programma che crea e si connette a * un database <i>cloudscape</i> */ public class SQLCloudscape { /** * Nome del driver JDBC di Cloudscape * Una volta installata la Java 2 EE si trova in * $J2EE_HOME/lib/cloudscape/cloudscape.jar su Unix e * %J2EE_HOME%\lib\cloudscape\cloudscape.jar su Windows */ static String driver = "COM.cloudscape.core.JDBCDriver"; /** * Stringa di connessione al database cloudscape * 'create = true' indica al driver di creare il database * se non esiste. Viene utilizzato se non ne viene fornito * uno dalla linea di comando */ static String url = "jdbc:cloudscape:clouddb;create = true"; /** * Utilizzato come comando SQL di default se non ne viene * passato uno sulla linea di comando */ static String sql = "SELECT * FROM SYS.SYSTABLES"; /** * main: entry del programma */ public static void main(string[] args) { try { if(args.length > 0) url = args[0]; 12

13 if(args.length > 1) sql = args[1]; // Carica il driver di Cloudscape Class c = Class.forName(driver); System.err.println("Caricato driver nella VM: " + c.tostring()); // Crea la connessione (crea il database) Connection conn = DriverManager.getConnection(url); System.err.println("Creata connessione: " + conn.tostring()); // Crea lo statement Statement stmt = conn.createstatement(); System.err.println("Creato statement: " + stmt.tostring()); // Esegue una query sulla tabella di sistema ResultSet rs = stmt.executequery(sql); System.err.println("Esecuzione query: " + sql); // La scansione result set dà tutte le tabelle // presenti nel database ResultSetMetaData rsmd = rs.getmetadata(); // prende il numero di colonne int cols = rsmd.getcolumncount(); while(rs.next()) { for(int i = 0; i < cols; ++i) { // le colonne 1, 2 System.out.print(rs.getString(i + 1)); // separatore di campi if(i < cols) System.out.print(" "); System.out.println(""); // Chiusura delle risorse rs.close(); stmt.close(); conn.close(); catch(exception e) { System.err.println("Messaggio err.: " + e.getmessage()); return; Segue lo script sqlcloudscape.bat che lancia il programma impostando correttamente l ambiente. REM REM Lancia programma SQLCloudscape per le query su database Cloudscape REM SET J2EE_HOME=D:\java\j2sdkee1.2 SET CLOUDSCAPE_HOME=D:\java\j2sdkee1.2\cloudscape SET WORK_HOME=D:\lavoro\sviluppo SET CLASSPATH=%CLASSPATH%;%J2EE_HOME%\lib\cloudscape\cloudscape.jar;%WORK_HOME% 13

14 java -Dcloudscape.system.home=%CLOUDSCAPE_HOME% esempi.cloudscape.sqlcloudscape %1 %2 La variabile d ambiente cloudscape.system.home indica dove creare il database se non specificato, come nel nostro caso. JDBC 1.1 core API: struttura del package java.sql Ecco nel grafico come si articolano le classi più utilizzate del package java.sql. In questa sezione affrontiamo in dettaglio le principali classi del package java.sql. DriverManager DriverManager.registerDriver() Questo metodo restituisce un enumerazione dei drivers caricati nella Virtual Machine. Per caricare un driver su utilizza di solito l istruzione Class.forName("com.informix.jdbc.IfxDriver"); I Driver JDBC hanno normalmente degli inizializzatori statici che registrano la classe stessa presso il DriverManager automaticamente. Ecco un esempio: public class IfxDriver extends { // blocco di inizializzazione statica static { // qualcosa del genere DriverManager.register(new IfxDriver()); 14

15 Questo metodo di registrazione viene detto implicito. Per registrare invece la classe del driver in modo esplicito si invoca il metodo registerdriver(). DriverManager.registerDriver(new Classe_del_Driver); Il thin driver di Oracle richiede la registrazione esplicita ad esempio, anche se il metodo più diffuso è quello implicito. È possibile fare in modo che la VM carichi automaticamente uno o più drivers JDBC. Per fare ciò occorre impostare la variabile d ambiente jdbc.drivers. DriverManager.getDrivers() Questo metodo permette di recuperare in forma di enumerazione l elenco dei drivers caricati nella VM. Il programma che segue utilizza getdrivers() per mostrare come effettivamente venga letta dalla VM la variabile d ambiente jdbc.drivers citata poco sopra. package esempi.sql; import java.sql.drivermanager; import java.sql.driver; import java.util.enumeration; /** * Esempio 01 - mostra la JVM * utilizza la variabile d'ambiente jdbc.drivers. */ public class Esempio01 { static public void main(string[] args) { // Mostra la variabile jdbc.drivers System.out.println("jdbc.drivers=" + System.getProperty("jdbc.drivers")); // Enumera i driver in memoria Enumeration e = DriverManager.getDrivers(); while(e.hasmoreelements()) { Driver driver = (Driver)e.nextElement(); System.out.println("Nome: " + driver.tostring()); System.out.println("JDBC Compliant: " + driver.jdbccompliant()); Ecco il risultato dell esecuzione del programma in due diversi casi. D:\lavoro\sviluppo>java esempi.sql.esempio01 jdbc.drivers=null D:\lavoro\sviluppo>java -Djdbc.drivers=com.informix.jdbc.IfxDriver esempi.sql.esempio01 jdbc.drivers=com.informix.jdbc.ifxdriver Nome: com.informix.jdbc.ifxdriver@f87ee844 15

16 JDBC Compliant: true D:\lavoro\sviluppo>java - Djdbc.drivers=com.informix.jdbc.IfxDriver:COM.cloudscape.core.JDBCDr iver esempi.sql.esempio01 jdbc.drivers=com.informix.jdbc.ifxdriver:com.cloudscape.core.jdbcdriver Nome: com.informix.jdbc.ifxdriver@faf36c3c JDBC Compliant: true Nome: COM.jbms._46._217@86b76c3c JDBC Compliant: false setlogstream() Questo metodo permette di impostare lo stream di log per le operazioni di JDBC. L applicazione che segue mostra come si utilizza il metodo impostando come stream di log un file sql.log. package esempi.sql; import java.io.*; import java.sql.*; /** * Esempio 02 - mostra strumenti di loggin di JDBC */ public class Esempio02 { /** * Stream di log di JDBC */ static PrintStream sqlstream = null; static { try { FileOutputStream fos = new FileOutputStream("C:\\temp\\sql.log"); sqlstream = new PrintStream(fos); catch(ioexception e) { System.err.println("ERRORE I/O: " + e.getmessage()); static public void main(string[] args) { try { // Carica il driver Cloudscape Class.forName("COM.cloudscape.core.JDBCDriver"); DriverManager.setLogStream(sqlstream); DriverManager.println("--- Sessione " + (new java.util.date()).tostring() + " ---"); // Crea connessione DriverManager.println("apertura connessione"); Connection conn = DriverManager.getConnection("jdbc:cloudscape:clouddb"); DriverManager.println("connessione aperta con successo"); // Chiude la connessione DriverManager.println("chiusura connessione"); conn.close(); DriverManager.println("connessione chiusa con successo"); 16

17 catch(exception e) { System.err.println("ERRORE: " + e.getmessage()); L output prodotto nel file C:\temp\sql.log è il seguente: --- Sessione Mon Oct 16 01:05:40 GMT+02: apertura connessione DriverManager.getConnection("jdbc:cloudscape:clouddb") trying driver[classname=com.jbms._46._217,com.jbms._46._217@8c4b62fb] getconnection returning driver[classname=com.jbms._46._217,com.jbms._46._217@8c4b62fb] connessione aperta con successo chiusura connessione connessione chiusa con successo Si notano, oltre ai nostri messaggi, alcuni messaggi di log della VM riguardanti la ricerca del driver associato all URL jdbc:cloudscape:clouddb utilizzato dal programma: questi messaggi non appaiono sulla console, quindi occorre esplicitamente impostare uno stream di log come mostrato (può anche essere System.out o System.err) per visualizzarli. Il programma che segue recupera il default (0) per il valore di login timeout. package esempi.sql; import java.sql.drivermanager; /** * Esempio 03 - mostra il valore di default di login timeout */ public class Esempio03 { static public void main(string[] args) { int timeout = DriverManager.getLoginTimeout(); System.out.println("Default Login Timeout " + timeout); getconnection() Restituisce l oggetto Connection. Il driver manager scorre l elenco dei drivers caricati nella VM e su ognuno invoca il metodo acceptsurl() per vedere se il driver comprende il protocollo di connessione richiesto dall applicazione. Se trova il driver adatto viene invocato il suo metodo connect() per ottenere la connessione. Esistono tre forme di getconnection(), da utilizzare a seconda di come si vogliono passare le proprietà della connessione. Il primo esempio: DriverManager.getConnection("jdbc:informixsqli:// mokauser;password=mokaifx"); 17

18 Il secondo esempio: DriverManager.getConnection("jdbc:informixsqli:// "mokauser", "mokaifx"); Il terzo esempio: Properties props = new Properties(); props.put("user", "mokauser"); props.put("user", "mokaifx"); Connection DriverManager.getConnection("jdbc:informixsqli:// props); createstatement() Crea l oggetto connessione utilizzato dall applicazione per l esecuzione dei comandi SQL. E- siste in due forme, per il supporto della nuova funzionalità di scrolling result set. gettransactionisolation() settransactionisolation() Si utilizzano per impostare il livello di isolamento delle transazioni per la sessione corrente. I possibili livelli di isolamento transazione sono riportati di seguito (in ordine di isolamento crescente, tra parentesi la relativa costante da utilizzare in settransactionisolation()). uncommitted read (TRANSACTION_READ_UNCOMMITTED). Questo livello di isolamento permette di leggere anche i dati in transazione, quindi dati che stanno quindi per essere modificati e non sono integri. committed read (TRANSACTION_READ_COMMITTED). Lettura di soli dati non in transazione. Se un altra sessione sta lavorando sui dati ai quali cerchiamo di accedere, la lettura viene bloccata. repeatable read (TRANSACTION_REPEATABLE_READ). Questo livello di isolamento vi garantisce non solo che i dati che leggete durante la vostra transazione siano integri ma, se all interno della stessa transazione leggete più volte gli stessi dati (ad esempio rifate la stessa query) riotterrete gli stessi risultati. Il livello di isolamento precedente non garantisce questa possibilità. serializable (TRANSACTION_SERIALIZABLE). È il livello di isolamento più alto per una transazione utente. Oltre a ovviare ai problemi precedenti, conosciuti come dirty read e non-repeteable read, permette di affrontare anche il problema dei phantom read, che si verifica quando un altra transazione inserisce ad esempio una nuova riga che soddisfa a una clausola di WHERE di una lettura all interno della vostra transazione. In tal caso i valori prece- 18

19 dentemente letti non sarebbero stati modificati ma vi capiterà di vedere dati nuovi (phantom) che prima non comparivano nel record set. Perché non impostare fin dall inizio, o prima di qualsiasi transazione, il massimo livello in modo da evitare in anticipo ogni problema? La risposta è semplice: l aumento del livello di isolamento di una o più sessioni utenti limita il grado di parallelismo del database, non riuscendo il server a eseguire le transazioni in modo concorrente. Ne risulta quindi un abbassamento delle performance. Il più delle volte è il sufficiente il livello di isolamento di default, che può essere reperito con il metodo DatabaseMetadata.getDefaultTransaction- Isolation(). Occorre conoscere d altra parte i diversi gradi di isolamento e quali specifiche violazioni evitano nel caso dobbiate scrivere programmi che effettuano modifiche critiche sui dati. commit() rollback() getautocommit() setautocommit() Questi quattro metodi si utilizzano insieme per avviare una transazione in modo programmatico, senza cioè inviare al database le istruzioni SQL classiche BEGIN WORK, COMMIT WORK, ROLLBACK. Normalmente tutte i comandi SQL eseguiti da un applicazione sono svolti in modalità autocommit. Ciò vuol dire che per ogni singolo comando SQL viene aperta e chiusa una transazione. Nel caso invece occorra rendere atomica una serie di operazioni SQL che hanno senso se eseguite insieme, disabilitare la modalità autocommit con l istruzione setautocommit(false); // disabilita autocommit e avvia transazione Questa istruzione automaticamente avvia una transazione non occorre insomma un ulteriore istruzione del tipo stmt.execute BEGIN WORK che sarà terminata con una delle due istruzioni commit() o rollback(). Vedremo in seguito esempi di utilizzo delle transazioni e dei metodi mostrati. Potete ovviamente utilizzare questi metodi solo se le transazioni per il database che state utilizzando sono supportate: per saperlo a priori utilizzate il metodo DatabaseMetadata.supports- Transactions(). preparestatement() preparecall() Si utilizzano questi due metodi rispettivamente per creare uno statement preparato e una stored procedure. 19

20 Se si prevede di utilizzare spesso la stessa istruzione SQL, conviene prepararla, ovvero spedirla al parser del db server in una forma tale che possa precompilarla per poi rieseguirla con i soli parametri variabili. Ad esempio, query come la seguente SELECT * FROM articoli WHERE nome = 'Nicola' AND cognome = 'Venditti' SELECT * FROM articoli WHERE nome = 'Giovanni' AND cognome = 'Puliti' possono essere preparate con la sintassi seguente SELECT * FROM articoli WHERE nome =? AND cognome =? In codice Java diventa ResultSet rs = null; PreparedStatement pstmt = conn.preparestatement("select * FROM articoli WHERE nome =? AND cognome =?"); // recupera articoli di Nicola Venditti pstmt.setstring(1,'nicola'); pstmt.setstring(1,'venditti'); rs = pstmt.executequery(); // recupera articoli di Giovanni Puliti pstmt.setstring(1,'giovanni'); pstmt.setstring(1,'puliti'); rs = pstmt.executequery(); In modo simile si esegue la chiamata a una stored procedure nel database. Statement Lo Statement è lo strumento che le applicazioni utilizzano per spedire comandi SQL al database. È un concetto generale valido non solo per Java. execute() executequery() executeupdate() Questi e in particolare gli ultimi due sono i metodi che utilizzerete per ogni operazione possibile sul database. Il primo è un metodo generico, utilizzabile per istruzioni SQL tipo DDL e DML; il secondo è specializzato per le query o in generale per operazioni che ritornano un result set; executeupdate(), si utilizza per tutte le operazioni che non ritornino un result set ma al più un update count (come nel caso di cancellazioni, inserimenti e aggiornamenti). Il primo metodo è interessante anche perché permette di eseguire in una sola volta istruzioni multiple separate dal punto e virgola ( ; ) come 20