Guida Metodologica Accesso ai Dati Oracle da Java

Transcript

1 Controllo delle copie Il presente documento, se non preceduto dalla pagina di controllo identificata con il numero della copia, il destinatario, la data e la firma autografa del Responsabile della Qualità, è da ritenersi copia informativa non controllata. Guida Metodologica Accesso ai Dati Oracle da Java SQC ver. 2 SQC VER. 2 Pag. 1/14

2 Sommario 1 Scopo e campo di applicazione 3 2 Riferimenti Controllo del Documento: Stato delle revisioni Documenti esterni Documenti interni Termini e Definizioni 3 3 Introduzione 4 4 La scelta del driver JDBC Tipologie di Driver JDBC I driver JDBC di Oracle Linee guida per la scelta del driver 5 5 Modalità di Connessione Come connettersi al DB con J2SE Come connettersi al DB con J2EE 6 6 L oggetto statement e le sue estensioni L interfaccia Statement L interfaccia PreparedStatement L interfaccia CallableStatement 9 7 I result set 10 8 Gestione delle eccezioni 11 9 Strategie di accesso ai dati Utilizzo delle Stored Procedure Gli oggetti Oracle Gli Entity Bean ORM: Toplink 14 SQC VER. 2 Pag. 2/14

3 1 Scopo e campo di applicazione Lo scopo di questo documento è fornire un set di linee guida da seguire durante la scrittura di una applicazione Java per l accesso ai dati residenti su un database Oracle. La prima parte del documento sarà dedicata all analisi delle classi coinvolte, mettendone in risalto le differenze e focalizzando l attenzione su vantaggi e svantaggi derivanti dall uso di ciascuna; la seconda parte sarà invece rivolta all individuazione della migliore strategia di accesso ai dati. Essendo il tema trattato di natura prettamente tecnica, ovvero corredato nella sua esposizione da diagrammi, codici d esempio, scenari comuni e casi reali, si ritiene necessario che il lettore possieda uno skill di base sull analisi e la realizzazione di applicazioni object oriented e Java; sono richiesti inoltre conoscenze elementari sui database relazionali, con particolare riferimento ad Oracle, e principi di PL/SQL. 2 Riferimenti 2.1 Controllo del Documento: Stato delle revisioni Vers. Descrizione delle modifiche apportate nella revisione alla versione precedente Cap. modificati 2 Revisione Logo Aziendale N.A. 2.2 Documenti esterni NORMA UNI EN ISO 9001: Sistemi di gestione per la qualità Requisiti; NORMA UNI EN ISO 9004: Sistemi di gestione per la qualità - Linee guida per il miglioramento delle prestazioni; NORMA UNI EN ISO 9000: Sistemi di gestione per la qualità Fondamenti e terminologia Mapping Associations from OODBs to RDBMs (Wolfgang Keller; 1995; sd&m München) Foundations of Object Relational Mapping (Mark L. Fussell; 1997) Java Programming with Oracle JDBC (Donald Bales; 2002; O'Reilly) Oracle9i: Application Developer's Guide - Object-Relational Features (William Gietz; 2002; Oracle Corporation) Thinking in Java, 3rd Edition (Bruce Eckel; 2003) Java Database Interaction Mechanism Using Oracle Reference Cursors (Ravi Kumar Buragapu; 2005) Build Superior Java Applications with Oracle TopLink - An Oracle White Paper (Donald Smith; 2005; Oracle Corporation) 2.3 Documenti interni Manuale della Qualità ACI Informatica; Sistema di Gestione per la Qualità vigente. Guida metodologica Linee Guida Naming & Coding Conventions per Java Guida metodologica Linee Guida - Naming & Coding Convention per Oracle Guida metodologica Java Best Practices Guida metodologica Accesso ai Dati Oracle Mediante Oggetti 2.4 Termini e Definizioni Per i termini, sigle e acronimi contenuti in questo documento si fa riferimento al Glossario dei termini utilizzati nel Sistema Qualità. RDBMS: (ingl.) Relational Data Base Management System. Sistema di gestione di un database relazionale, in cui i dati sono organizzati in tabelle accessibili tramite SQL, un linguaggio di interrogazioni specializzato. ODBC: acronimo per Open DataBase Connectivity. Standard sviluppato verso la fine degli anni ottanta da Microsoft e IBM per lo scambio dei dati tra database diversi. JDBC: (acronimo di Java DataBase Connectivity) interfaccia scritta in linguaggio Java per l accesso a database relazionali. JNDI: (Java Naming and Directory Interface) JNDI è una gerarchia di risorse organizzate in directory e disponibili per tutte le classi Java. L interfaccia JNDI consente la separazione tra la definizione delle risorse in uso dalle applicazioni e il codice dell applicazione stessa. Tra le risorse gestite da JNDI sono compresi DataSources, code JMS ed EJB. SQC VER. 2 Pag. 3/14

4 3 Introduzione Quando si realizza un applicazione Java che si basa su RDMBS, si utilizza l'api JDBC (Java DataBase Connectivity) per dialogare con il database. La comprensione dei meccanismi di funzionamento del RDMBS che si sta utilizzando è una premessa importante per riuscire a scrivere applicazioni che sono in grado di soddisfare i requisiti prestazionali richiesti. In questo documento saranno fornite delle linee guida da seguire quando la base dati risiede su Oracle, aiutando lo sviluppatore nella scelta delle classi e della strategia migliori. L'obiettivo ultimo che ci si prefigge è quello di ottenere applicazioni robuste, veloci e scalabili. Quando si sceglie un database è importante capire per cosa esso è stato progettato e quali sono le tipologie di applicazioni in cui è veramente conveniente utilizzarlo. Oracle è conosciuto come un database per applicazioni entreprise in cui si gestiscono enormi quantità di dati e di utenti concorrenti; è in questi ambiti che Oracle mostra il meglio di se e soprattutto giustifica il suo prezzo. Lo scenario di riferimento per questo documento sarà quindi quello di un ambiente di produzione multiutente in cui si cercherà di individuare i meccanismi utili ad assicurare prestazioni adeguate al crescere degli utenti connessi al sistema e dei dati salvati nel database. 4 La scelta del driver JDBC Stabilire la connessione al database è uno dei primi passi da eseguire quando un applicazione deve interagire con una base dati. Questo passo può apparire facile o addirittura banale, ma spesso la scelta del driver JDBC avviene senza cognizione di causa per mancanza di adeguate informazioni. In questo capitolo si discuterà dei differenti tipi di driver e dei vantaggi di ciascuno di essi. I driver JDBC si differenziano per il linguaggio con cui sono implemantati, Java puro o linguaggio macchina (codice nativo), e per il modo con cui la connessione è effettuata. 4.1 Tipologie di Driver JDBC La Sun ha definito quattro categorie di driver JDBC che si differenziano per l architettura che adottano. Type 1: JDBC bridge driver Questo tipo di driver implementano un bridge per connettere un client Java a driver di terze parti, quale, per esempio, potrebbe essere un driver ODBC. Il bridge JDBC-ODBC della Sun è l esempio più illustre di questo tipo di driver. Type 2: Native API Questo tipo di driver fornisce una interfaccia Java a delle API native. Il driver OCI (Oracle Call Interface) è un esempio di driver di tipo 2. Poiché un driver di tipo due è implementato usando codice nativo è ragionevole aspettarsi prestazioni superiori rispetto ad un driver Java puro. Type 3: Network Protocol Questo tipo di driver comunica tramite il protocollo di rete con un middle-tier server; subito dopo il middle-tier server inoltra la comunicazione al DB server. Oracle non adotta driver JDBC di tipo tre, tuttavia fornisce un programma, il Connection Manger, che in combinazione con driver di tipo quattro può essere assimilato ad un JDBC driver di tipo tre. Type 4: Native Protocol Questo tipo di driver, scritto interamente in Java, comunica direttamente con il database. Non necessita di codice nativo sulla macchina client. Il driver JDBC Thin di Oracle è un esempio di driver JDBC di tipo quattro. 4.2 I driver JDBC di Oracle Oracle mette a disposizione degli sviluppatori driver di tipo due e di tipo quattro. Tralasciando i driver usati server-side, ovvero quelli utilizzati all interno del database, le possibili scelte sono: JDBC OCI Driver È un driver di tipo due che usa l interfaccia nativa OCI di Oracle. Ne esistono varie versioni, tante quante sono le versioni della Oracle Call Interface, e richiede l installazione di Oracle client sulla macchina remota. JDBC Thin Driver È un driver Java puro e non richiede nessuna installazione di software aggiuntivo sulla macchina client. JDBC-ODBC bridge Non è propriamente un driver JDBC per Oracle, ma è un driver di tipo uno fornito dalla Sun. Permette la comunicazione tra le applicazioni Java e qualsiasi database (quindi anche Oracle) per cui è stato definito un ODBC. È qui riportato per completezza. SQC VER. 2 Pag. 4/14

5 La figura successiva esemplifica la modalità di accesso ad un database Oracle usando le tre diverse opzioni a disposizione. JDBC-ODBC Driver Driver ODBC Oracle Call Interface JDBC OCI Driver Oracle Listener Oracle RDBMS JDBC Thin Driver Figura Linee guida per la scelta del driver Ciò che immediatamente si nota in Figura 1 è il differente numero di strati software presenti in ciascuna soluzione: si passa da una comunicazione diretta tra Thin Driver e listener ai ben due presenti tra il bridge JDBC-ODBC e Oracle. Alla luce di questa e delle precedenti considerazioni possiamo fornire le seguenti linee guide per la scelta del driver JDBC: 1. Per le applicazioni client/server si consiglia fortemente l uso del Thin Driver per ragioni di portabilità; questa soluzione non richiede l installazione di Oracle Client e diminuisce i costi di configurazione e manutenzione del software. 2. Per le applet la scelta è obbligata: il Thin Driver. Non è possibile, infatti, fare assunzioni sul software installato sul client. 3. Per le applicazioni batch che devono lavorare massivamente sui dati si suggerisce l uso dell OCI Driver. Infatti, l uso di codice nativo garantisce prestazioni superiori. La stessa Oracle Corporation raccomanda questa soluzione in scenari di questo tipo. 4. Nelle applicazioni Three-Tier si consiglia l uso dell OCI Driver, in quanto la controindicazione dovuta ai costi di configurazione viene meno (il client Oracle è necessario solo nel Tier che effettivamente si collega al DB), mentre resta valida le considerazioni del punto 3 sulle migliori prestazioni del codice nativo. 5 Modalità di Connessione 5.1 Come connettersi al DB con J2SE Una volta individuato il driver JDBC da utilizzare, i passi da seguire per connettersi ad un DB Oracle sono: Aggiungere le istruzioni di import per puntare le classi necessarie. Registrare il driver JDBC. Formattare opportunamente l URL di connessione al database. Invocare il metodo getconnection() sulla classe DriverManager. Di seguito è fornito un esempio di connessione ad una base dati: import java.sql.connection; import java.sql.drivermanager; import java.util.properties; public class JdbcTest { public static void main(string[] args) SQC VER. 2 Pag. 5/14

6 { Connection pconnection = null; Properties pproperties = null; try { pproperties = new Properties(); pproperties.put( user, scott ); pproperties.put( password, tiger ); pproperties.put( defaultrowprefetch, 30 ); pproperties.put( defaultbatchvalue, 5 ); Class.forName("oracle.jdbc.driver.OracleDriver"); pconnection = DriverManager.getConnection( "jdbc:oracle:thin:@ :1521:hr", pproperties); System.out.println("Connection done"); Esempio 1 Come si può notare il metodo getconnection usato accetta, oltre che l URL del DB (o stringa di connessione), un oggetto di tipo Properties. Ciò permette di poter definire, oltre utente e password, anche altri parametri di sessione; tra i più importanti si segnalano defaultrowprefetch, che indica il numero di righe prefetched, e defaultbatchvalue, che indica il numero di query batch che innesca l esecuzione delle stesse. Un valore ottimale assegnato a questi parametri potrebbe portare a migliorare le prestazioni del sistema. 5.2 Come connettersi al DB con J2EE In ambito J2EE l accesso al database è mediato dall Application Server. I parametri di connessione (URL, UserName, Password, ) sono configurati dal deployer. Lo sviluppatore può ottenere la connessione al database richiedendola all Application Server usando un reference (o riferimento). Sarà compito del deployer mappare il riferimento sulla risorsa JNDI appropriata secondo le indicazioni del gruppo applicativo. Connection pconnection = null; Context pcontext = new InitialContext(); DataSource pdatasource = (DataSource) pcontext.lookup("java:comp/env/jdbc/appdatasource"); pconnection = pdatasource.getconnection(); pconnection.setautocommit(false); pconnection.commit(); pconnection.close(); Esempio 2 Nell esempio appena presentato il riferimento jdbc/appdatasource rappresenta il datasource dell applicazione (di cui lo sviluppatore conosce solo i metadati). Al momento del deploy dell enterprise application tale reference sarà agganciato alla risorsa JNDI effettivamente utilizzata dell applicazione in modo del tutto trasparante allo sviluppatore. Qualunque sia l ambito di utilizzo di JDBC (J2SE o J2EE) è bene ricordare che Oracle offre il supporto alle transazioni. È sempre buona norma rendere esplicito il comportamento delle transazioni. L istruzione pconnection.setautocommit(false) disabilita l autocommit per la connessione pconnection. Il SQC VER. 2 Pag. 6/14

7 comportamento di default di Oracle stabilisce che l autocommit è abilitato. I metodi commit e rollback della classe Connection effettuano rispettivamente la commit e il rollback delle transazioni pendenti. È buona norma di programmazione non lasciare connessioni pendenti al DB. Tutte le connessioni aperte devono essere rilasciate utilizzando il metodo close della classe Connection. 6 L oggetto statement e le sue estensioni 6.1 L interfaccia Statement L oggetto Statement è creato su una connessione ad un database attiva attraverso il metodo createstatement( ) e permette di eseguire istruzioni SQL DDL (Data Definition Language: CREATE, ALTER, DROP) e DML (Data Manipulation Language: SELECT, INSERT, UPDATE, DELETE); al contrario le istruzioni DCL (Data Control Language: COMMIT, SAVEPOINT, ROLLBACK e SETTRANSACTION) sono eseguite con invocazioni a metodi specifici sull oggetto Connection. L oggetto Statement può utilizzare il metodo execute( ) per eseguire ogni possibile istruzione SQL valida. Il metodo execute( ) può ritornare un valore a runtime per determinare se c è un result set e quindi utilizzare getresultset( ) per ottenere i dati; è possibile utilizzare il metodo getupdatecount( ) per determinare a runtime il numero di righe interessate da una operazione di aggiornamento sul DB. Tuttavia, quando si ha la necessità di eseguire degli statement di INSERT, UPDATE o DELETE è preferibile usare il metodo executeupdate( ) che ha un comportamento specializzato per le operazioni di aggiornamento sul database; per ragioni analoghe è sempre preferibile usare il metodo executequery( ) nel caso di query di selezione. Il codice seguente fornisce un esempio d uso dell oggetto Statement boolean bresultset = false; Statement pstatement = null; try { pstatement = pconnection.createstatement( ); bresultset = pstatement. execute("select 'Hello ' USER from dual"); Esempio 3 Chi ha esperienza di programmazione Java conosce già l interfaccia Statement; in ogni caso i JavaDoc, descrivendone in dettaglio gli attributi e i metodi, costituiscono un irrinunciabile punto di riferimento per chiunque. Cosa meno nota è che JDBC definisce anche altre due interfacce, PreparedStatement e CallableStatement, che estendono Statement definendo una gerarchia a tre livelli secondo quanto mostrato dal seguente diagramma delle classi. Figura L interfaccia PreparedStatement Analogamente allo Statement, un PreparedStatement può essere usato per inserire, aggiornare, cancellare e selezionare dati. Tuttavia i PreparedStatement sono statement precompilati che possono essere riusati per eseguire in modo più efficiente istruzioni SQL identiche con differenti valori. I SQC VER. 2 Pag. 7/14

8 PreparedStatement interrogano Oracle una sola volta per ottenere i metadati della query, mentre gli Statement effettuano una interrogazione per ogni esecuzione. Inoltre, poiché è utilizzato il bind delle variabili, il database compila e conserva in cache l istruzione SQL riusandola nelle esecuzioni seguenti per migliorare le performance. I PreparedStatement sono anche utili in quanto alcuni tipi di valori, come per esempio I BLOB, le collezione, ecc non sono rappresentabili come SQL text. Con i PreparedStatement si usano dei puntiinterrogativi (?) come segnaposto all interno dello statement SQL; successivamente questi sono sostituiti con i valori appropriati usando i metodi accessori setxxx( ), disponibili per ogni tipo di dato. Quanto appena detto potrebbe far credere che l uso di oggetti PreparedStatement assicuri sempre prestazioni maggiori. Ciò perché gli oggetti PreparedStatement interrogano Oracle una sola volta per ottenere i metadati della query rendendo le query successive alla prima fino al 50% più veloci. Bisogna considerare, però, che il binding delle variabili, la compilazione e il caching della query introducono un certo overhead. I test illustrati da Donald Bales [2.1.3] dimostrano che l overhead dovuto all uso di un PreparedStatement viene compensato solo dopo 65 esecuzioni della query. Ne consegue che per un piccolo numero di esecuzioni potrebbe essere vantaggioso usare un oggetto Statement piuttosto che un oggetto PreparedStatement. Il codice seguente costituisce un esempio d uso dell oggetto PreparedStatement try { PreparedStatement ppreparedstatement; ppreparedstatement = pconnection. preparestatement( insert into + MYTABLE ( MYFIELD1, MYFIELD1) values (?,? ) ); ppreparedstatement setstring(1, "AAA"); ppreparedstatement.setint(2, 123) ppreparedstatement.execute(); ppreparedstatement = pconnection. preparestatement( update MYTABLE set MYFIELD1 =? + where MYFIELD2 =? ); ppreparedstatement setstring(1, "AAA"); ppreparedstatement.setint(2, 123) ppreparedstatement.execute(); ppreparedstatement = pconnection. preparestatement( delete MYTABLE where MYFIELD1 =? ); ppreparedstatement setstring(1, "AAA"); ppreparedstatement.execute(); ppreparedstatement = pconnection. preparestatement( select?, MYFIELD2 from MYTABLE + where MYFIELD2 =? ); ppreparedstatement setstring(1, "AAA"); ppreparedstatement.setint(2, 123) ppreparedstatement.execute(); Esempio 4 Si fa notare che il punto interrogativo nella select list dell ultima query rappresenta un valore costante e non il nome di una colonna. SQC VER. 2 Pag. 8/14

9 6.3 L interfaccia CallableStatement Un oggetto CallableStatement è usato per invocare stored procedure. In Oracle, con il termine generale stored procedure ci si riferisce all insieme delle standalone stored function, standalone procedure, packaged function e procedure. Le stored procedure Oracle possono essere scritte in Java o in PL/SQL. Come noto, le stored procedure sono state inventate per eseguire operazioni data-intensive che non possono essere compiute usando solamente SQL. Le stored procedure vengono eseguite all interno del database; le loro performance non risentono quindi dei tempi di latenza su rete. Per invocare una stored procedure è necessario conoscerne il nome e la natura dei parametri passati alla procedura. Nel caso di una funzione è necessario conoscere anche il tipo del valore di ritorno. È possibile ottenere queste informazioni interrogando il data dictionary di Oracle come mostrato nell esempio seguente. SQL> select * from user_procedures; OBJECT_NAME PROCEDURE_NAME AGG ALIMENTASTORICO ALIMENTASTORICO NO ALLINEA_SEQUENCE_TIPOLOGICA NO ASSEGNATUTTIIMETODI NO CREATE_TYPES ALTERTYPES NO CREATE_TYPES LAUNCHTYPESCREATOR NO DATETOCHAR NO GETCODICETIPOLOGICA NO GETDATAFINEVALIDITA NO GETDATAFORINSUPD NO SQL> desc ALIMENTASTORICO; PROCEDURE ALIMENTASTORICO Nome argomento Tipo In/Out Predef.? P_TABLENAME VARCHAR2 IN P_STRISTANZADB VARCHAR2 IN DEFAULT Esempio 5 Chiamare una stored procedure da Java è un processo in cinque fasi. Le operazioni da svolgere sono, nell ordine: Formulare un callable statement: cioè preparare una stringa opportunamente formattata per invocare una stored procedure. È possibile usare indifferentemente la sintassi SQL92 o Oracle /* Sintassi SQL92 */ {? = call [schema.][package.] function_name [(?,?,)] {call [schema.] [package.]procedure_name[(?,?,)]) /* Sintassi Oracle */ begin?:=[schema.][package.]function_name[(?,?,)]; end; begin [schema.][package.]procedure_name[(?,?,)]; end; Esempio 6 Creare un un CallbleStatement un CallableStatement è creato invocando il metodo preparecall( ) su un oggetto Connetion passando la stringa preparata nel passo precedente. CallableStatement pcallablestatement = null; try { pcallablestatement = pconnection. preparecall("{? = call function_name (?,?, ) "); Esempio 7 Registrare ogni parametro di output SQC VER. 2 Pag. 9/14

10 Per poter ottenere i dati da una chiamata a stored procedure occorre registrare i parametri di OUT o IN OUT prima di eseguire il CallableStatement. Per far ciò si usa il metodo registeroutparameter( ) dell oggetto CallableStatement. pcallablestatement.registeroutparameter(1, Types.DOUBLE, 2); Esempio 8 Settare i parametri di input: Analogamente ai prepared statement, questa operazione è eseguita usando i metodi accessori setxxx( ) passando la posizione del carattere segnaposto del callable statement e un opportuno valore. pcallablestatement.setstring(1, smystring); Esempio 9 Eseguire il callable statement: Dopo aver svolto le suddette operazioni preliminari un callable statement può essere eseguito utilizzando il metoto execute ( ) dell oggetto CallableStatement. pcallablestatement.execute(); Esempio 10 Si sottolinea ancora una volta che un CallableStatement è un PreparedStatement (Vedi Figura 2); perciò, tutto quanto detto in precedenza sulle performance dei PreparedStatement rispetto ad un oggetto Statement è integralmente applicabile anche ai CallableStatement. 7 I result set Come abbiamo avuto modo di vedere nel capitolo precedente l utilizzo del metodo executequery( ) della classe Statement ritorna un oggetto di tipo ResultSet. Un ResultSet contiene i risultati di una query su un database. All interno di un database i dati risiedono in tabelle contenenti righe e colonne; l organizzazione di ResultSet riflette quella di una tabella. Un ResultSet fornisce un insieme di metodi accessori per navigare attraverso i dati estratti, mentre altri permettono di prelevare i valori (di tipi SQL standard o proprietari Oracle) o i metadati della query. Tali metodi sono ben noti agli sviluppatori Java e non saranno quindi oggetto di questa trattazione. Ad ogni modo i JavaDoc ne forniscono un elenco completo e dettagliato. Quando un oggetto ResultSet è ritornato da uno Statement, il suo cursore è inizialmente posizionato prima della prima riga del set di risultati. Per tale ragione, la prima invocazione del metodo next( ) posiziona il cursore sulla prima riga estratta. Il metodo next( ) restituisce un valore booleano (false se non esiste nessuna riga successiva a quella corrente) e può essere quindi utilizzato per verificare la presenza di dati rispondenti ai parametri di selezione. Il metodo next( ) è tipicamente utilizzato all interno di un loop, come mostra l esempio seguente: ResultSet presultset = null; Statement pstatement = null; try { pstatement = pconnection.createstatement( ); presultset = pstatement. executequery("select owner, table_name + from all_tables"); while (presultset.next( )) { Esempio 11 Con le specifiche JDBC 1.0 i ResultSet potevano essere in sola lettura e navigabili in avanti (cioè non esisteva il metodo previous( ) e i suoi derivati). Con le specifiche JDBC 2.0 i ResultSet possono essere navigati in qualsiasi direzione e possono anche essere aggiornabili. Per implementare queste funzionalità il metodo createstatement( ) della classe Connection è stato sovraccaricato definendo il metodo Statement createstatement(int resultsettype, int resultsetconcurrency) SQC VER. 2 Pag. 10/14

11 Per il parametro resultsettype, esistono tre possibili valori costanti (attributi static final della classe ResultSet): TYPE_FORWARD_ONLY Crea un ResultSet forward-only. TYPE_SCROLL_INSENSITIVE Crea un ResultSet navigabile in entrambe le direzioni insensibile alle modifiche apportate al database. Se una qualche modifica viene apportata su Oracle mentre il ResultSet è ancora aperto, l applicazione Java non vedrà tali modifiche a meno che, naturalmente, non apra un nuovo ResultSet. TYPE_SCROLL_SENSITIVE Contrariamente al precedente, crea un ResultSet in grado di riflettere immediatamente sull applicazione Java i cambiamenti avvenuti sul DB. Anche in questo caso il ResultSet è navigabile in entrambe le direzioni. Per il parametro resultsetconcurrency, esistono due possibili costanti (attributi static final della classe ResultSet) CONCUR_READ_ONLY Crea un ResultSet read-only. CONCUR_UPDATABLE Crea un ResultSet aggiornabile. Oracle implementa la navigabilità dei ResultSet usando una memory cache client-side. Per tale ragione i paramentri TYPE_SCROLL_* dovrebbero essere usati con cautela in quanto potrebbero avere degli impatti negativi sulle performance delle applicazioni a causa dell elevato uso di memoria della JVM. Per implementare i ResultSet aggiornabili, Oracle usa il ROWID, un valore che identifica univocamente ogni rigo nel database. Sebbene non sia esplicitamente stata richiesta dall applicazione, questo valore viene estratto per ogni record di un set aggiornabili portando ad un maggiore volume di dati in transito sulla rete e residenti sulla JVM. Anche in questo caso, quindi, i record aggiornabili devono essere usati con cautela. Il metodo createstatement( ) crea ResultSet forward-only e read-only. 8 Gestione delle eccezioni Le eccezioni costituiscono il meccanismo adottato da Java per gestire le situazioni inattese (eccezionali). La gestione delle eccezioni fa parte del bagaglio culturale di base degli sviluppatori Java ed illustrarlo non rientra negli obiettivi di questo documento. Al contrario, questo capitolo si prefigge lo scopo di esaminare più in dettaglio la classe java.sql.sqlexception. Una SQLException può esere sollevata a seguito del verificarsi di eventi inattesi sia nel driver che nel database. Quando tale eccezione viene lanciata un oggetto della classe SQLException sarà passato alla clausola catch per gestire l anomalia. Oltre ai metodi ereditati dalla superclasse, una SQLException espone i seguenti per ottenere informazioni aggiuntive sull eccezione sollevata: geterrorcode( ) Restituisce il codice d errore Oracle associate all eccezione. getmessage( ) Restituisce il messaggio d errore del driver JDBC, se l eccezione è stata sollevata dal Driver, o il codice d errore e il messaggio, se l eccezione è stata sollevata dal database. getsqlstate( ) Restituisce la stringa XOPEN SQLstate. Occorre tenere presente durante la programmazione che questo metodo può anche ritornare null. getnextexception( ) Ritorna il successivo oggetto Exception della catena delle eccezioni. Utilizzando le informazioni restituite dall oggetto Exception e catturando l eccezione è possibile far seguire al programma un flusso opportuno. Naturalmente la scelta della strategia per il recupero delle situazioni anomale non può prescindere dal tipo di errore. Per questa ragione è sempre necessario avere a disposizione la lista completa dei codici d errore di Oracle con la loro spiegazione. SQC VER. 2 Pag. 11/14

12 9 Strategie di accesso ai dati 9.1 Utilizzo delle Stored Procedure Navigando su internet e leggendo gli articoli sulla stampa specializzata, sembra affermarsi il trend dell utilizzo delle stored procedure per l accesso ai dati. La stessa Oracle corporation suggerisce questa strategia. In effetti i vantaggi derivanti da questa tecnica sono numerosi ed importanti. Tra i primi segnaliamo che l uso delle stored procedure permette di astrarre le classi dalla struttura fisica del database. Supponiamo per esempio di voler ottenere la fabbrica, il tipo e la serie di un autoveicolo estraendola da un database composto da una sola tabella con la seguente struttura logica. Figura 3 La nostra stored procedure, chiamata per esempio GET_FTS_DATA, conterrà al suo interno una istruzione SQL del tipo SELECT Fabbrica, Tipo, Serie FROM Veicolo WHERE Esempio 12 e verrà invocata in ogni punto del codice Java in cui è necessario ottenere queste informazioni. Se nel corso dell evoluzione dell applicazione lo schema del database dovesse cambiare (per esempio per esigenze di normalizzazione) diventando il seguente: Figura 4 Il solo cambiamento necessario sarebbe localizzato nella stored procedure dove la select diventerebbe del tipo: SELECT Fabbrica, Tipo, Serie FROM Fabbrica INNER JOIN Veicolo ON Fabbrica.Id_Fabbrica = Veicolo.Id_Fabbrica WHERE Esempio 13 SQC VER. 2 Pag. 12/14

13 Il codice Java rimarrebbe immutato continuando a chiamare la procedura GET_FTS_DATA, ignaro dei cambiamenti nel database. Altre tecniche di astrazione, quali ad esempio file di configurazione contenenti le istruzioni SQL o l utilizzo di viste, non sono altrettanto sicure o nascondono solo parzialmente la struttura fisica del DB. Le stored procedure evitano problemi derivanti dalla duplicazione del codice SQL. Bisogna infatti considerare che il database può essere condiviso da più applicazioni, non tutte necessariamente in piattaforma J2EE. Evitare la proliferazione e la ripetizione del codice SQL porta ad avere una architettura complessiva delle applicazioni aziendali più stabile e manutenibile e una logica di accesso al database uniforme. Ciò, a sua volta, rende il tuning del database e delle query più agevole e veloce; i benefici di questa attività saranno subito propagati a tutte le applicazioni. Come abbiamo avuto modo di sottolineare in precedenza una query effettuata utilizzando le stored procedure è di solito più veloce: l hoverhead dovuto alla compilazione delle procedure, sebbene presente, è limitato alla sola prima esecuzione. In uno scenario di applicazioni enterprise e multiutente o batch con esecuzioni ripetute della query i vantaggi sono evidenti. Vantaggi sono presenti anche dal punto di vista della sicurezza: l utilizzo esclusivo di stored procedure consente di assegnare agli utenti applicativi, i più esposti dal punto di vista della sicurezza, le sole grant di execute. In questo modo, se anche l utenza e la password dovessero venire intercettate, un utente malizioso avrebbe comunque un accesso limitato alle risorse e ai dati del database. Le stored procedure agevolano anche il monitoraggio da parte del DBA, permettendo di sfruttare a pieno le potenzialità di strumenti quali statspack. In quanto componenti software destinati ad un ambiente di esecuzione diverso da Java, le stored procedure appesantiscono la gestione della configurazione. Anche il ciclo di vita del software richiede una gestione più dispendiosa, dato che i passaggi da un ambiente ad un altro richiedono necessariamente l intervento del gruppo DBA oltre che dei deployer. Inoltre è sempre concreto il rischio di una loro eccessiva proliferazione: in casi limite si giunti ad avere procedure distinte per query che si differenziano solo per il tipo di ordinamento del set di dati ritornato; l utilizzo delle stored procedure richiede quindi una analisi della logica di accesso più attenta ed oculata. 9.2 Gli oggetti Oracle L uso degli oggetti Oracle rappresenta una possibile interessante funzionalità aggiuntiva alle stored procedure. La documentazione Oracle riporta la capacità di immagazzinare tipi di dati definiti dall utente fin dalla versione 8i. Utilizzando gli oggetti Oracle è possibile fare in modo che le strutture dati di Java relative a business level e data level vadano a coincidere eliminando completamente lo strato di traduzione. Per raggiungere questo obiettivo occorre: 1. Definire un tipo di oggetto oracle in cui gli attributi corrispondano a delle colonne in una tradizionale tabella relazionale. 2. Creare una vista di oggetti per estrarre i dati. 3. Creare un trigger INSTEAD OF per rendere la vista aggiornabile. 4. In alternativa al punto precedente è possibile di definire all interno degli oggetti Oracle dei metodi che si occupano della serializzazione dell oggetto. Il mapping tra le proprietà dell oggetto Java e dell oggetto Oracle verrà reso attraverso l implementazione da parte dell oggetto Java di due interfacce: OraData e OraDataFactory. Tali interfacce definiranno i processi di serializzazione e deserializzazione del dato. La scelta di implementare degli oggetti dotati di metodi per salvare le proprie variabili membro sembra essere la più comoda in quanto assegna ad ogni oggetto la responsabilità di serializzare se stesso sul database e concentra in un unica struttura Oracle (l oggetto appunto) i dati dell oggetto (proprietà) e la logica di persistenza (metodi). In questo caso, tuttavia, è necessario passare l oggetto ad una stored procedure; questa modalità di accesso ai dati diventa quindi una estensione della precedente. Sebbene le funzionalità necessarie all uso di questa tecnica siano state rilasciate da tempo solo con la versione del database, Oracle riesce a supportare pienamente questa tecnica. Occorre inoltre sottolineare che la letteratura non riporta ancora casi reali di utilizzo in applicazioni enterprise di grandi dimensioni, ne dati affidabili sulle performance. Ciononostante questa tecnica è stata sperimentata ed utilizzata in azienda in ambito PRA e nelle applicazioni del Centro Servizi (CS). SQC VER. 2 Pag. 13/14

14 9.3 Gli Entity Bean Gli entity bean sono la soluzione J2EE al problema della persistenza. Le specifiche Sun consigliano l uso degli Entity Bean, Container Maneged Persistence (CMP) o Bean Managed Persistence (BMP), per leggere e scrivere i dati in un database. I vantaggi architetturali derivanti dal loro utilizzo sono evidenti: un entity bean è un componente che incapsula e implementa una entità del business layer. L entità incapsulata è tipicamente indipendente dall applicazione client che usa l entity bean. Come conseguenza uno stesso entity bean può essere usato da molte applicazioni client. Esistono inoltre altri vantaggi pratici derivanti dall uso degli entity; gli entity bean permettono infatti una gestione fine-grained delle transazioni, senza la necessità di preoccuparsi di fornire i demarcatori di inizio e fine transazione. Inoltre gli entity bean (attraverso il container) offrono anche funzionalità di connection pooling e caching dei bean; l accesso ai servizi di mail e di messaging è facilitato. Sfruttando l interfaccia javax.ejb.timer è possibile creare entity bean temporizzati, oggetti particolarmente utili, anche se di fatto introducono uno strato di business logic all'interno del dominio dei dati, per cui violano in qualche modo alcune delle best practice J2EE, secondo le quali un entity è una rappresentazione OO di dati resi persistenti da qualche parte. Utilizzando gli EJB di entità non è necessario scrivere statement JDBC riducendo i tempi di sviluppo. Se si sceglie di usare i CMP la gestione delle transazioni avviene senza la necessità di scrivere codice e la sicurezza è gestita dall application server. Esistono tuttavia anche delle controindicazioni: i CMP non gestiscono il join tra tabelle. Inoltre, diversamente dagli oggetti DAO, sia i CMP che i BMP sono disponibili solo su piattaforme J2EE e la portabilità tra application server diversi non è sempre garantita. Dato che l accesso ai dati è comunque mediato dall application server si può riscontrare una perdita di performance. Gli oggetti DAO supportano tabelle (con o senza chiave primaria), viste e stored procedure, mentre gli entity bean supportano solo tabelle con chiavi primarie. 9.4 ORM: Toplink Con l Object Relational Mapping (ORM) la persistenza viene resa utilizzando particolari strumenti, detti motori di persistenza (il più noto nella comunità open source è Hibernate), i quali non sono altro che framework che, in modo meno invasivo possibile, consentono il salvataggio ed il recupero dello stato di un oggetto sulla base dati. La persitenza è ottenuta attraverso la reflection, che consente nella piattaforma Java di ispezionare il contenuto degli oggetti per conoscerne i metodi e gli attributi, e quindi per accedere agli uni o agli altri. Questo tipo di persistenza trasparente somiglia da vicino a quella promessa dei bean di entità CMP, dove è il component container a svolgere una funzione che corrisponde alla descrizione data sopra. La tecnologia EJB, però, richiede dei descrittori più complessi, ed impone l'utilizzo di interfacce e superclassi presenti nel framework EJB, come javax.ejb.entitybean e javax.ejb.sessionbean. I motori di persistenza lavorano invece con semplici POJO, acronimo che sta per Plain Old Java Object. Un POJO indica un semplice, tradizionale oggetto Java, privo degli orpelli che solitamente vengono imposti dai framework per questa o quella funzione, come le sopracitate interfacce EJB. Anche la Oracle Corporation ha acquistato ed evoluto un motore per l OR Mapping chiamato Toplink. I maggiori benefici derivanti dall uso di Toplink sono: Portabilità: Toplink supporta tutti i maggiori application server e database, fornendo certificazioni e test report per tutte le release e le patch. Tuttavia Toplink mostra il meglio di se quando usato insieme agli altri software della casa produttrice: Oracle Application Server e Oracle DB. Aumento della produttività: Toplink permette la configurazione dei metadati attraverso dei file XML amministrati graficamente tramite degli editor che ne agevolano la gestione. Le maggiori criticità riguardano: Performance: le performance di Toplink variano sensibilmente al variare dei parametri di configurazione ed in particolar modo al variare delle dimensioni della shared object cache. Per ottenere prestazioni ottimali è necessaria una attenta fase di tuning. Gestione: per schema con un numero elevato di tabelle, la gestione dei numerosi file di configurazione può risultare critica. La comunità degli utenti pone generalmente a 50 il limite massimo di tabelle gestibili con un qualsiasi strumento per ORM. Flessibilità: accessi particolarmente articolati potrebbero essere difficili o impossibili da realizzare con uno strumento di questo genere richiedendo comunque il ricorso a stored procedure invocate usando JDBC. SQC VER. 2 Pag. 14/14