PostgreSQL-Java

Transcript

PostgreSQL-Java

Java & PostgreSQL:
da JDBC a Pl/Java
(passando per org.postgresql.Driver)
Ing. Luca Ferrari, PhD
[email protected]
Italian PostgreSQL Users Group
ITPug
Synopsis
Questa presentazione vuole fungere da punto di
riferimento per gli sviluppatori Java che vogliano scrivere
applicazioni capaci di gestire i dati contenuti in un cluster
PostgreSQL.
In questa presentazione verranno mostrate le principali
tecniche per la connettività Java verso PostgreSQL
(tramite JDBC), il funzionamento interno del driver JDBC
ufficiale nonché come “estendere” il database
PostgreSQL con tecnologia Java tramite Pl/Java.
Gli esempi di applicazioni/database qui riportati sono a
puro scopo didattico.
Java & PostgreSQL – Luca Ferrari
2 di 182
Database didattico
CREATE TABLE corso
(
corsopk serial NOT NULL, Chiave surrogata della tabella corso.
corsoid character varying(10), Chiave reale della tabella corso. descrizione text, Descrizione del corso requisiti text, Elenco dei requisiti richiesti data date, Data in cui si tiene il corso n_ore integer, Numero di ore del corso.
materiale oid, Materiale didattico distribuito con il corso ts timestamp with time zone DEFAULT ('now'::text)::timestamp,
CONSTRAINT corso_chiave_surrogata PRIMARY KEY (corsopk),
CONSTRAINT corso_chiave_reale UNIQUE (corsoid),
CONSTRAINT corso_n_ore_check CHECK (n_ore > 0 AND n_ore < 8)
)
3 di 182
Database didattico
CREATE TABLE partecipante
(
partecipantepk serial NOT NULL, Chiave surrogata della tabella nome character varying(20), Nome del partecipante.
cognome character varying(20), ts timestamp with time zone DEFAULT ('now'::text)::timestamp,
partecipanteid character varying(30),
CONSTRAINT partecipante_chiave_surrogata PRIMARY KEY (partecipantepk),
CONSTRAINT partecipante_chiave_reale UNIQUE (partecipanteid)
)
4 di 182
Database didattico
CREATE TABLE j_corso_partecipante
(
j_corso_partecipante_pk serial NOT NULL, Chiave surrogata corsopk integer NOT NULL,
partecipantepk integer NOT NULL,
CONSTRAINT j_corso_partecipante_chiave_surrogata PRIMARY KEY (j_corso_partecipante_pk),
CONSTRAINT j_corso_partecipante_corsopk FOREIGN KEY (corsopk)
REFERENCES corso (corsopk) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT j_corso_partecipante_partecipantepk FOREIGN KEY (partecipantepk)
REFERENCES partecipante (partecipantepk) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
5 di 182
JDBC:
applicazioni client
6 di 182
JDBC
JDBC (Java DataBase Connectivity) è un'API a
livello SQL, ossia consente di inglobare comandi
SQL nelle proprie applicazioni Java.
JDBC fornisce un'unica API CLI per l'accesso a
database relazioni eterogenei. L'applicazione non
necessita di adattamenti qualora il motore
database cambi!
Applica il famoso concetto “Write Once, Run
Everywhere” alla connettività database.
Si noti che l'idea non è nuovissima: ODBC si propone già come
API unificata.
Non è indispensabile utilizzare JDBC!
7 di 182
Application & Driver APIs
JDBC può essere divisa in due parti fondamentali: Application API
e Driver API.
Le Application API comprendono tutti gli elementi che
un'applicazione Java usa per la connessione ad un database.
Le Driver API forniscono la base per la scrittura di un driver
specifico per un determinato motore relazionale (es. PostgreSQL).
Grazie alla suddivisione in due parti, JDBC consente la scrittura di
applicazioni portabili e database-independent.
All'URL
All'URL
http://developers.sun.com/product/jdbc/drivers
http://developers.sun.com/product/jdbc/drivers
èèpossibile
possibileverificare
verificarel'esistenza
l'esistenzadidiun
undriver
driverJDBC
JDBC
per
ogni
motore
relazionale
conosciuto.
per ogni motore relazionale conosciuto.
8 di 182
Application API vs Driver API
Java Application
Application
ApplicationAPI
API
Driver
DriverAPI
API
Database
Engine
9 di 182
Livelli JDBC
Le Driver API riconoscono quattro modalità di implementazione
differenti, chiamate livelli o type dei driver JDBC:
type 1 (JDBC-ODBC bridge): viene sfruttato un accesso
ODBC (che deve esistere!).
●
type 2 (Native API Drivers): il driver richiama, tramite JNI,
codice nativo (es. C/C++) per la connettività.
●
type 3 (Network Drivers): il driver si collega (via TCP/IP) ad un
componente lato server che si interfaccia a sua volta con il
database server.
●
type 4 (Pure Java): il driver si collega direttamente al
database server e comunica utilizzando un protocollo
opportuno.
●
10 di 182
Livelli JDBC: schema riassuntivo
JDBC Type 1
ODBC Driver
JDBC Type 2
Native Driver
Database
Engine
Java Application
JDBC Type 3
Translator (e.g., local
JDBC type 2)
JDBC Type 4
11 di 182
JDBC API
12 di 182
Classi principali JDBC
Le principali classi/interfaccie della libreria JDBC
(java.sql.* e javax.sql.*) sono:
DriverManager: rappresenta un repository di istanze di
Driver per ogni database server. Ci si rivolge a questa
classe per creare una connessione ad uno specifico
database (tramite un URL).
Driver: rappresenta il componente incaricato di stabilire la
connessione con il database server. Può essere caricato
all'interno del programma (es. tramite reflection) o
specificando la proprietà jdbc.drivers nel momento di
invocazione della JVM:
java Djdbc.drivers=org.postgresql.Driver myApp
13 di 182
Classi principali JDBC (2)
Connection: rappresenta una connessione al server
database. Tramite di essa è possibile interagire con il
database stesso.
Statement: implementa una query SQL di qualunque tipo;
viene usato per l'esecuzione di un comando sul database
server. Si specializza in due sotto-interfaccie:
PreparedStatement: una query SQL precompilata e
dotata di wrapping dei parametri.
CallableStatement: una query SQL che coinvolge
una stored procedure.
14 di 182
Classi principali JDBC (3)
ResultSet: implementazione di un cursore SQL.
Contiene un riferimento alla riga dei risultati dall'esecuzione di
un comando SQL. Disponde di una serie di metodi per il
posizionamento rispetto alle righe e per l'estrazione dei valori
di ogni colonna.
ResultSetMetaData: informazioni aggiuntive su un
ResultSet, quali nomi e numero delle colonne, nome dello
schema corrente, etc.
DatabaseMetaData: fornisce informazioni aggiuntive sul
database stesso, quali versione, stored procedures, foreign
keys, etc.
SQLException: classe base di ogni eccezione JDBC.
15 di 182
Tipica applicazione JDBC
Caricamento
Caricamentodel
del
driver
necessario
driver necessario
Istanziazione
Driver
Connessione
Connessionealal
database
database
(Connection)
(Connection)
Registrazione presso
DriverMagaer
[while ResultSet.next()]
<INVIO>
Lettura
Letturadel
del
ResultSet
ResultSet
Simile all'esecuzione del
comando
psql -h host -U utente db
Simile alla scrittura
di una query sulla
linea di comando di
psql
Esecuzione
Esecuzionedello
dello
Statement
Statement
Creazione
Creazionedidiuno
uno
Statement
Statement
Chiusra
Chiusrarisorse
risorseassociate
associateaa
ResultSet
ResultSet ee Statement
Statement
Chiusura
Chiusura
connessione
connessione
(Connection)
(Connection)
16 di 182
Classi accessorie
La libreria fornisce una serie di classi aggiuntive
per il mapping fra i tipi SQL e i tipi Java (Types),
la gestione di Large Object Data (Clob, Blob),
date (Date), timestamp (Timestamp) e array
(Array).
Come estensioni sono presenti anche le classi
per la gestione dei data source (DataSource), dei
row set (RowSet) e dei relativi eventi (e.g.,
RowSetEvent, StatetementEvent).
17 di 182
Connessione al database
public static void main(String[] args)
throws Exception{
try{
// classe del driver
String driverName = "org.postgresql.Driver";
// url di connessione
String databaseURL =
"jdbc:postgresql://localhost/pgdaydb";
// caricamento della classe del driver
Class driverClass = Class.forName(driverName);
// creazione dell'istanza del driver
Driver driver = (Driver) driverClass.newInstance();
18 di 182
Connessione al database
//
//
//
//
a questo punto il driver è registrato
presso il DriverManager (il driver di PostgreSQL
si registra automaticamente al DriverManager
appena la sua classe viene caricata)
// essendo il driver caricato e registrato posso
// ottenere una connessione al database
Connection connection =
DriverManager.getConnection(databaseURL,
"luca",
// username
"xxx"
// password
);
// una volta ottenuta una connessione al database
// e' possibile interagire con esso per via di
// oggetti di tipo Statement
19 di 182
Creazione di uno Statement
// creazione di una query e di uno statement
// da usare (la query mostra i corsi
// che contengono java nella descrizione
// e i relativi iscritti)
String query = "SELECT c.corsoid, c.descrizione, c.data,
c.n_ore, p.nome, p.cognome " +
" FROM (corso c LEFT JOIN j_corso_partecipante
j ON c.corsopk = j.corsopk) " +
" LEFT JOIN partecipante p ON p.partecipantepk
= j.partecipantepk " +
" WHERE c.descrizione ilike '%java%' ";
// notare che lo Statement non e' ancora associato
// a nessuna query
Statement statement = connection.createStatement();
// effettuo la query
ResultSet rs = statement.executeQuery(query);
20 di 182
Analisi dei risultati: ResultSet
// visualizzo i dati ottenuti dalla query: l'oggetto
// ResultSet (rs) rappresenta un cursore dei risultati
// che può essere scorso.
while( rs.next() ){
System.out.println("######");
// posso ottenere i dati di una riga chiamando i
// metodi getXXX (XXX = tipo di dato) e specificando
// il numero della colonna (partendo da 1) o il suo
// nome simbolico
System.out.println("Id-Corso e descrizione: "
+ rs.getString(1) + " " + rs.getString(2));
System.out.println("Data e numero ore: "
+ rs.getDate(3) + " " + rs.getInt(4));
System.out.println("Iscritto: "
+ rs.getString("nome") + " "
+ rs.getString("cognome"));
}
21 di 182
Fine del programma e gestione delle
eccezioni
// chiusura della connessione
connection.close();
}
}catch(SQLException exception){
// eccezione SQL (problema nella query, errore del
// server, etc.)
}catch(ClassNotFoundException ex){
// classe del driver JDBC non trovata
}catch(InstantiationException ex){
// errore di reflection (classe driver non
// istanziabile)
}catch(IllegalAccessException ex){
// errore di reflection (classe driver non
// accessibile)
}
}
22 di 182
Esecuzione
Riassunto:
● Caricamento del driver PostgreSQL (necessario solo all'avvio del thread
principale dell'applicazione);
● Creazione di una connessione specificando l'URL di connessione;
● Creazione di uno Statement;
● Esecuzione dello Statement;
● Lettura dei risultati tramite il ResultSet;
● Chiusura delle risorse.
23 di 182
Come fa il DriverManager a scegliere il Driver
opportuno?
Il DriverManager stabilisce quale sia il Driver da utilizzare per una
connessione sulla base dell'URL di connessione (ogni driver accetta il
proprio subprotocol):
protocol:subprotocol://HOSTNAME/DB_NAME
HOSTNAME: specifica
l'indirizzo IP/nome dell'host
ove è in esecuzione il
database.
DB_NAME: nome del
database cui ci si intende
connettere.
jdbc:postgres://localhost/pgdaydb
protocol: specifica il
dominio di appartenenza di
questo URL. Indica che l'URL
si riferisce ad una
connessione database
(JDBC).
subprotocol: specifica il driver che si
deve utilizzare. Viene utilizzato da
DriverManager per fare il lookup
dell'istanza di Driver da restituire per
gestire la connessione al database.
24 di 182
Considerazioni sul caricamento del driver
Il caricamento e l'istanziazione del driver JDBC può
avvenire attraverso reflection o direttamente:
// reflection
Class driverClass =
Class.forName(“org.postgresql.Driver”);
Driver driverInstance = driverClass.newInstance();
// istanziazione diretta
Driver driverInstance = new org.postgresql.Driver();
I driver hanno sempre un costruttore di default senza argomenti,
I driver hanno sempre un costruttore di default senza argomenti,
e quindi sono sempre istanziabili mediante reflection.
e quindi sono sempre istanziabili mediante reflection.
25 di 182
Considerazioni sul ResultSet
Un ResultSet rappresenta un cursore sui risultati di una query. Il
posizionamento fra le righe del cursore avviene tramite metodi specifici, quali
next() e previous().
Ogni ResultSet è legato allo Statement che lo ha generato; se lo
Statement viene alterato il ResultSet è automaticamente invalidato!
Esistono metodi per recuperare il valore di ogni colonna secondo il tipo di
appartenenza (String, int, Date, ...):
<tipo_Java> get<tipo_Java>(int colonna)
<tipo_Java>get<tipo_Java>(String nomeColonna)
Ogni tipo SQL viene mappato in un tipo Java (e viceversa) mediante una specifica
tabella
di
conversione
(http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.
html). Tale tabella può essere estesa dall'utente per mappare i tipi user defined.
SiSipresti
prestiattenzione
attenzionealalfatto
fattoche,
che,contrariamente
contrariamentealla
allalogica
logica
degli
array,
le
colonne
sono
numerate
partendo
da
1!
degli array, le colonne sono numerate partendo da 1!
26 di 182
ResultSet: errori frequenti
Si richiama getXXX(..) con un
indice di colonna errato (maggiore)
rispetto al numero di colonne estratte
dalla query.
Si richiama getXXX(..) prima di
aver chiamato almeno una volta
next().
27 di 182
Esecuzione di un
INSERT/UPDATE/DELETE
// creazione di una query e di uno statement
// da usare per inserire un nuovo corso
String query = "INSERT INTO corso(corsoid,descrizione)
VALUES('Java_adv', 'Corso avanzato su Java/JDBC') ";
// chiedo al server di eseguire la query e
// di fornirmi il numero di righe "toccate"
// tutte le query che modificano i dati vanno eseguite
// attraverso il metodo executeUpdate(..)
int rows = statement.executeUpdate(query);
if( rows > 0)
System.out.println("Inserimento effettuato con
successo:" + rows + " righe inserite");
// chiusura della connessione
connection.close();
28 di 182
Esecuzione
Riassunto:
● Caricamento del driver PostgreSQL (necessario solo all'avvio del thread
principale dell'applicazione);
● Creazione di una connessione specificando l'URL di connessione;
● Creazione di uno Statement;
● Esecuzione dello Statement;
● Lettura del valore di ritorno dell'esecuzione dello Statement, tale valore
indica il numero di righe toccate dalla query;
● Chiusura delle risorse.
29 di 182
Compilazione del driver
30 di 182
Driver JDBC per PostgreSQL
PostgreSQL fornisce un driver JDBC conforme ai livelli 2,3 e 4. Il sito
web del progetto è http://jdbc.postgresql.org, dal quale è
possibile scaricare il driver (in formato binario o sorgente), navigare la
documentazione Javadoc della parte public delle API.
E' presente una mailing list specifica: pgsql[email protected]; gli attuali mantainer del Driver sono Dave Cramer, Kris Jurka, Oliver
Jowett.
31 di 182
Decompressione dei sorgenti
I sorgenti vengono rilasciati sotto forma di archivio
compresso (tarball):
postgresqljdbc8.2504.src.tgz
E' possibile decomprire
programma tar:
i
sorgenti
usando
il
tar xzvf postgresqljdbc8.2504.src.tgz
ottenendo una directory che contiene l'albero dei
sorgenti
ls l postgresqljdbc8.250
rwrr 1 luca luca 259 20061201 13:02 build.properties
rwrr 1 luca luca 21469 20061129 05:00 build.xml
drwxrxrx 2 luca luca 4096 20061201 13:22 doc
rwrr 1 luca luca 1542 20050111 09:25 LICENSE
drwxrxrx 3 luca luca 4096 20061201 13:22 org
rwrr 1 luca luca 3769 20041023 00:24 README
rwxrxrx 1 luca luca 495 20041107 23:15 updatetranslations.sh
32 di 182
Compilazione: requisiti
Per compilare il driver JDBC è necessario utilizzare Apache
Ant (http://ant.apache.org), uno strumento di compilazione
automatico per Java.
Ant è uno strumento concettualmente simile a make, ma
ottimizzato per la gestione dei progetti Java. Esso stesso è
scritto in Java, e questo ne facilita la fruibilità nello sviluppo
di componenti Java.
Ant necessita della presenza di un file di build (solitamente
build.xml) che contiene i task del processo di compilazione.
E' possibile specificare proprietà di compilazione mediante
file di proprietà Java (file properties).
33 di 182
Compilazione: build
Il file di build del driver è build.xml, e può essere omesso
nell'invocazione di ant:
[luca@fluca:/sviluppo/java/contribsrc/postgresqljdbc8.2504.src]$ ant
Buildfile: build.xml
all:
prepare:
check_versions:
check_driver:
driver:
compile:
[javac] Compiling 144 source files to /sviluppo/java/contribsrc/postgresqljdbc8.2
504.src/build
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with Xlint:unchecked for details.
jar:
[jar] Building jar: /sviluppo/java/contribsrc/postgresqljdbc8.2
504.src/jars/postgresql.jar
BUILD SUCCESSFUL
Total time: 5 seconds
[luca@fluca:/sviluppo/java/contribsrc/postgresqljdbc8.2504.src]$
34 di 182
Compilazione: risultato
Al termine del processo di compilazione viene generato un
file postgresql.jar nella sottodirectory jars:
[luca@fluca:/sviluppo/java/contribsrc/postgresqljdbc8.2504.src]$ ls l jars/
total 436
rwrr 1 luca luca 441337 20070331 11:22 postgresql.jar
[luca@fluca:/sviluppo/java/contribsrc/postgresqljdbc8.2504.src]$
Il file jar prodotto deve essere incluso nel classpath
corrente affinché i programmi Java possano caricare il
driver.
$ export CLASSPATH=`pwd`/jars/postgresql.jar:$CLASSPATH
$ echo $CLASSPATH
/sviluppo/java/contribsrc/postgresqljdbc8.2504.src/jars/postgresql.jar:
$
35 di 182
Compilazione: risultato (2)
Un altro file importante viene generato: Driver.java
$ ls l org/postgresql/Driver.java*
rwrr 1 luca luca 29517 20070331 11:21 org/postgresql/Driver.java
rwrr 1 luca luca 29523 20051124 07:18 org/postgresql/Driver.java.in
$
Prima
della
compilazione infatti il solo file
Driver.java.in è presente. Il file Driver.java viene
generato dinamicamente durante il processo di build,
a seconda del livello JDBC del driver.
36 di 182
Compilazione in Eclipse
Definire un nuovo
progetto basato su un
file Ant esistente.
(1)
(2) Selezionare il file di
build dalla directory dei
sorgenti; specificare le
proprietà del progetto.
37 di 182
Compilazione in Eclipse (2)
(3) Ricercare il file
build.xml
tramite il modulo Ant
di Eclipse.
38 di 182
Compilazione in Eclipse (3)
(4) Eseguendo il file di build il progetto viene
compilato.
39 di 182
JDBC 2, 3 o 4?
Il driver JDBC di Postgresql supporta solo i
livelli JDBC 2,3 e 4.
L'albero dei sorgenti
include i package per
ogni versione JDBC.
$ ls org/postgresql/ l
...
drwxrxrx 3 luca luca 4096 20061201 13:23 jdbc2
...
$
La
decisione
su
quale
livello
di
driver
(org.postgresql.Driver) viene presa durante il processo
di build in base alla versione della JVM.
In particolare la versione viene stabilita sulla base della Java
Virtual Machine installata sul sistema.
40 di 182
Driver.java.in
Il file org.postgresql.Driver.java.in è un file che viene
tramutato nel driver Java vero e proprio durante il
processo di build Ant.
Al suo interno il file Driver.java.in contiene dei
segnaposti per le classi JDBC del livello opportuno.
41 di 182
Scelta del livello JDBC
Il
file
contiene
build.xml
un target,
check_versions,
che
controlla quale versione
di JVM sia disponibile
e, di conseguenza,
quale versione di driver
sia la più appropriata.
A seconda del livello stabilito
viene impostata a true la
proprietà jdbcX.
42 di 182
Scrittura del livello JDBC
Il target driver si occupa della scrittura del file
Driver sostituendo i marcaposto al suo interno con
le classi del livello JDBC scelto.
Si noti che viene utilizzata la funzionalità di filtro
(filter) di Ant per la sostituzione dei marcaposto
(token) con le classi concrete.
Diverse altre classi sono specificate con lo stesso
procedimento.
43 di 182
Scrittura del livello JDBC (2)
Viene fatto un controllo sulla proprietà jdbcX,
impostata
precedentemente
dal
target
check_versions.
(1)
44 di 182
(2) Vengono impostati i token marcaposto da
sostituire nel file Driver.java.in; ogni token
specificato in build.xml trova corrispondenza con
@token@ in Driver.java.in Java & PostgreSQL – Luca Ferrari
45 di 182
(3) Il file Driver.java.in viene copiato in Driver.java
applicando le condizioni di filtro.
46 di 182
JDBC:
tipi di Statement
47 di 182
PreparedStatement
Un PreparedStatement è un oggetto che memorizza uno
statement SQL precompilato, che può essere parametrizzato
e che può eseguire più efficientemente di uno Statement
normale.
L'idea è di precompilare un comando SQL parziale e di
completarlo successivamente, al momento in cui
l'esecuzione sia necessaria.
Lo statement precompilato può poi essere riutilizzato più
volte, cambiando eventualmente i parametri di esecuzione.
Un PreparedStatement è una sottointerfaccia di Statement!
Essendo
Essendouno
unostatement
statementparametrizzabile,
parametrizzabile,PreparedStatement
PreparedStatementfornisce
forniscedei
deimetodi
metodi
setXXX
setXXXeegetXXX
getXXXper
perimpostare
impostarei iparametri
parametrididiesecuzione.
esecuzione.
48 di 182
Prepared Statement
// creazione di una query di inserimento e dello
// statement precompilato per la sua esecuzione
String query = "INSERT INTO corso(corsoid,descrizione)
VALUES(?,?) ";
PreparedStatement statement =
connection.prepareStatement(query);
// inserisco alcuni corsi fornendo gli opportuni
// parametri al server
int rows = 0;
for(int i = 0; i < 10; i++){
String corsoid = "corso_" + i;
String descrizione = "Nessuna descrizione ";
// impostazione dei parametri nello statement
statement.setString(1, corsoid);
statement.setString(2, descrizione);
// eseguo lo statement (non devo specificare una query
// poiché lo statement è già stato precompilato)
rows += statement.executeUpdate();
}
49 di 182
Considerazioni: PreparedStatement
Un PreparedStatement utilizza una sintassi speciale per
le query SQL: ogni carattere ? viene usato come un
marcatore per un parametro che verrà specificato in
seguito.
In maniera duale ad un ResultSet vengono forniti dei
metodi setXXX(numpar, value).
Il vantaggio dei PreparedStatement è che possono essere
memorizzati e precompilati dal database server, aumentado le
prestazioni nel caso di cicli (l'ottimizzatore potrebbe però
stabilire piani diversi a seconda della selettività dei parametri).
Si
Sipresti
prestiattenzione
attenzionealalfatto
fattoche
che
i iparametri
parametrisono
sononumerati
numeratipartendo
partendoda
da1!1!
50 di 182
Statement vs PreparedStatement
Statement:
PreparedStatement:
✔ query statiche o poco variabili;
✔ query parametriche;
✔ nessuna
necessità
escaping dei parametri.
✔ query
base
da
eseguire
ciclicamente a seconda di
parametri run-time;
di
✔ escaping di parametri usati nella
query stessa.
L'utilizzo di PreparedStatement è preferibile in molte situazioni!
51 di 182
CallableStatement
L'interfaccia CallableStatement viene usata in maniera
analoga ai PreparedStatement per l'invocazione di una
Stored Procedure.
La sintassi utilizzata per l'invocazione è la seguente:
{ call stored_procedure(?,?,...) }
Viene specificato il nome della stored procedure da invocare,
seguito dalla lista di eventuali parametri.
La funzione viene invocata con il metodo executeQuery() che
restituisce un ResultSet.
52 di 182
JDBC:
Utilizzo avanzato
53 di 182
Esecuzione di comandi arbitrari
Si supponga di voler creare una vista definita come segue:
CREATE VIEW vw_partecipanti AS SELECT c.corsoID, c.descrizione, c.data, p.cognome, p.nome FROM partecipante p JOIN corso c ON c.corsoPK = p.corsoPK ORDER BY c.corsoID, p.cognome, p.nome
Come si può notare
l'esecuzione della query non
produce alcun risultato (in
termine di numero di righe
modificate) pur alterando la
struttura del database.
54 di 182
Esecuzione di comandi arbitrari
// creazione di uno statement
// preparazione della query
String sql = "CREATE VIEW vw_partecipanti AS SELECT c.corsoID, c.descrizione, c.data, p.cognome, p.nome FROM partecipante p JOIN corso c ON c.corsoPK = p.corsoPK ORDER BY c.corsoID, p.cognome, p.nome";
int result = statement.executeUpdate(sql);
System.out.println("Risultato di esecuzione: " + result);
55 di 182
JDBC: creazione della procedura
// creazione di uno statement
// preparazione della funzione
StringBuffer buffer = new StringBuffer(1000);
buffer.append( "CREATE OR REPLACE FUNCTION ...”); buffer.append(" RETURNS void AS $BODY$ DECLARE ...”);
// chiamata della stored procedure
int result = statement.executeUpdate(buffer.toString());
System.out.println("Risultato della creazione della procedura: " + result);
56 di 182
JDBC: invocazione della procedura
// invocazione della funzione
String sql = "{ call f_nuovo_corso(?,?,?) }";
// preparazione della chiamata e impostazione dei parametri
CallableStatement cStatement = connection.prepareCall(sql);
cStatement.setInt(1, 2);
cStatement.setString(2, "Corso2009");
Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.DAY_OF_MONTH, 7);
calendar.set(Calendar.MONTH, 7);
calendar.set(Calendar.YEAR, 2009);
cStatement.setDate(3, new java.sql.Date(calendar.getTimeInMillis()) );
// invocazione della funzione
ResultSet resultSet = cStatement.executeQuery();
// in questo caso non ho risultati.... Java & PostgreSQL – Luca Ferrari
57 di 182
CallableStatement
L'interfaccia CallableStatement viene usata in maniera
analoga ai PreparedStatement per l'invocazione di una Stored
Procedure.
La sintassi utilizzata per l'invocazione è la seguente:
{ call stored_procedure(?,?,...) }
{ ?= stored_procedure(?,?,...) }
Viene specificato il nome della stored procedure da invocare,
seguito dalla lista di eventuali parametri.
L'invocazione avviene tramite il metodo executeQuery() che
restituisce un ResultSet.
E' possibile registrare parametri di input/output e ottenerne il valore
direttamente dallo statement.
58 di 182
Batch
L'interfaccia Statement consente l'esecuzione batch di
una serie di comandi SQL:
public void addBatch(String sql)
mediante tale metodo è possibile assegnare una serie di
istruzioni SQL da eseguire sequenzialmente in un
momento successivo.
L'esecuzione del gruppo di comandi avviene mediante il
metodo executeBatch(), che restituisce i singoli valori
di ritorno dell'esecuzione di ogni comando.
public int[] executeBatch()
59 di 182
Batch: un primo esempio
// creo uno statement
Statement statement = connetion.createStatement();
// imposto i comandi da eseguire nel batch
String sql = “INSERT INTO ...”;
// aggiungo questa istruzione al batch
statement.addBatch(sql);
// nuova istruzione da aggiungere al batch
sql = “INSERT INTO ...”;
statement.addBatch(sql);
...
// eseguo il batch
int result[] = statement.executeBatch();
// controllo i risultati di ogni comando
for(int i=0; i<result.length; i++)
System.out.println(“Comando “+(i+1)+” risultato “+ result[i]);
60 di 182
Batch & PreparedStatement
L'utilizzo dei batch agevola i casi in cui siano presenti cicli.
E' possibile utilizzare oggetti PreparedStatement al fine di
unire
i
vantaggi
di
un'esecuzione
batch
e
della
parametrizzazione dei comandi SQL.
// query parametri
String sql = “UPDATE corso SET descrizione=?
WHERE corsoID=?”;
PreparedStatement statement = connection.prepareStatement(sql);
for(int i=0; i< 10; i++){
statement.setString(1, descrizione[i]);
statement.setString(2, id[i]);
statement.addBatch();
}
// esecuzione
int result[] = statement.executeBacth();
61 di 182
Batch: considerazioni
Solitamente l'utilizzo di un batch risulta più
efficiente che l'esecuzione delle singole
operazioni in modo separato (ottimizzazione da
parte del driver).
Si presti attenzione al fatto che un batch è
differente da una transazione, tuttavia può essere
usato per rendere più compatto (e quindi
leggibile) il codice di una transazione.
62 di 182
Scrollable ResultSet
Uno scrollable ResultSet è un tipo particolare
ResultSet che offre una funzionalità di scrolling.
di
E' possibile muoversi attraverso le righe in avanti e indietro,
saltare righe, posizionarsi in modo relativo o assoluto, etc.
Il tipo di scrolling deve essere specificato a livello di creazione
dello Statement, specificando il tipo di scrolling (e di
aggiornabilità)
come
parametri
del
metodo
createStatement(..), in modo da consentire al database
di gestire le risorse.
IlIldriver
driverPostgreSQL
PostgreSQLutilizza
utilizzainternamente
internamenteun
unVector
Vectorper
per
contenere
contenereleletuple
tupledel
delResultSet;
ResultSet;mediante
medianteun
unindice
indice
riesce
a
garantire
lo
scrolling
di
tali
tuple.
riesce a garantire lo scrolling di tali tuple.
63 di 182
Tipo di scrolling
Il tipo di un ResultSet può essere specificato tramite tre valori
predefiniti:
ResultSet.TYPE_FORWARD_ONLY (1003) è il classico
ResultSet che può essere consultato solo in avanti.
ResultSet.TYPE_SCROLL_INSENSITIVE
(1004)
può
essere consultato in entrambe le direzioni ma non riflette
cambiamenti fatti al database mentre è aperto.
ResultSet.TYPE_SCROLL_SENSITIVE (1005) può essere
consultato in entrambe le direzioni e riflette ogni
cambiamento apportato.
Il tipo di scrolling può essere ricavato a tempo di esecuzione
tramite il metodo
int ResultSet.getType();
64 di 182
Posizionamento all'interno del ResultSet
L'interfaccia ResultSet mette a disposizione diversi metodi di
posizionamento:
beforeFirst(), afertLast() restituiscono true se si ci
si trova oltre la prima o l'ultima riga.
next(), previous() muovono di una riga in avanti o
indietro il cursore.
absolute(int), relative(int) spostano il cursore alla
riga specificata in modo assoluto o relativo (dalla
posizione corrente). Un indice negativo considera lo
spostamento all'indietro (es. -1 sposta all'ultima riga nel
caso di posizionamento assoluto o alla riga precedente nel
caso di posizionamento relativo).
getRow() ritorna il numero di riga (valore assoluto) a cui
si è posizionati correntemente.
65 di 182
Esempio di scrollable ResultSet
// ottengo il result set di una query
ResultSet rs = statement.executeQuery();
while( rs.next() ){
// esecuzione in avanti (solo righe pari)
int numero_riga = rs.getRow();
if( (numero_riga % 2) == 0 ){
System.out.println("######");
System.out.println("Id-Corso e descrizione: "
+ rs.getString(1) + " " + rs.getString(2));
}
}
// torno indietro e processo solo le righe dispari
while( rs.previous() ){
}
if( (numero_riga % 2) != 0 ){...}
66 di 182
ResultSet aggiornabili
JDBC v2 permette di aggiornare (inserire,
modificare, cancellare) le righe di una query
usando
direttamente
il
ResultSet
corrispondente.
In sostanza non si è obbligati a creare un
comando di update/insert ma si può modificare il
valore di una colonna direttamente operando sui
risultati di una query.
E' un tentativo di nascondere i dettagli SQL e di
rendere il sistema più Object-Oriented.
67 di 182
ResultSet aggiornabili (2)
Per rendere tutto ciò possibile l'interfaccia ResultSet
include una serie di metodi simili a quelli per la
definizione dei parametri di un PreparedStatement.
Ad esempio:
updateString(int column, String value);
updateInt(int column, int value);
...
Esistono
poi
dei
metodi
speciali
per
aggiornare/inserire/cancellare e aggiornare i valori della
riga corrente:
updateRow();
insertRow();
deleteRow();
refresh();
68 di 182
Tipo di aggiornabilità
Il tipo di un ResultSet, relativamente alla sua aggiornabilità, può
essere specificato tramite due valori predefiniti:
ResultSet.CONCUR_READ_ONLY (1007) è
ResultSet che non può essere aggiornato.
il
classico
ResultSet.CONCUR_UPDATABLE (1008)
può
essere
aggiornato e quindi supporta inserimento, modifica e
cancellazione di righe.
Il tipo di aggiornabilità può essere ricavato a tempo di
esecuzione tramite il metodo
int ResultSet.getType();
69 di 182
Inserimento di una riga
L'inserimento di una riga in un ResultSet è
un'operazione leggermente più complessa
rispetto all'aggiornamento.
Occorre infatti istruire il ResultSet affinché
prepari posto per i valori della riga che si vuole
inserire, assegnare tali valori e confermare
(salvare) l'inserimento della nuova riga.
Se il ResultSet è di tipo scroll sensitive la riga
inserita sarà visibile senza bisogno di
aggiornamenti del ResultSet stesso.
70 di 182
Inserimento di una riga:
un approccio visuale
La procedura di inserimento di una nuova riga è simile alla
procedura usata in molti programmi visuali di accesso e modifica
dei database:
(1) viene ottenuto il ResultSet
relativo ad una specifica query;
(2) si passa oltre l'ultima riga,
usando una riga vuota come
spazio
temporaneo
per
l'inserimento dei valori. Si usa il
metodo
moveToInsertRow();
(3) vengono salvati i valori
inseriti. Si usa il metodo
insertRow().
71 di 182
Inserimento di una riga in un ResultSet
// processo il result set ed inserisco una nuova riga (max 4)
// ad ogni riga pari (non significa DOPO ogni riga pari!)
while (rs != null && rs.next()) {
if( ((numero_riga % 2) == 0) && inserite < 4 ){
// inserisco una nuova riga in fondo al result set
rs.moveToInsertRow();
rs.updateString(1, "CorsoRS" + numero_riga);
rs.updateString(2, "Prova di inserimento da ResultSet");
rs.insertRow();
// torno alla riga cui ero prima dell'inserimento
rs.moveToCurrentRow();
inserite++;
}
String corsoID = rs.getString(1);
String descrizione = rs.getString(2);
System.out.println("Riga numero " + numero_riga + " " + corsoID + " = " + descrizione);
}
72 di 182
JDBC:
Transazioni
73 di 182
JDBC e transazioni
Il driver JDBC lavora in modalità auto-commit: ogni
istruzione eseguita tramite uno Statement viene
automaticamente confermata.
E' come se si eseguissero transazioni monocomando.
Per prendere il controllo sulla transazione e
segnarne l'inizio e la fine (BEGIN-END) è
necessario disabilitare l'auto-commit del driver e
forzare un esplicito commit/rollback.
74 di 182
Schema di funzionamento
// disabilito auto commit
connection.setAutoCommit(false);
// effettuo del lavoro, INSERT, UPDATE, ecc. e tengo
// traccia se devo fare un rollback
...
rollback = true;
// tutto fatto
if( ! rollback )
connection.commit();
else
connection.rollback();
connection.setAutoCommit(true);
// ripristino auto-commit
75 di 182
Transazioni: livello di isolamento
E' possibile impostare il livello di isolamento di una transazione.
I livelli di isolamento sono memorizzati come costanti (interi)
nell'oggetto Connection e possono valere:
Connection.TRANSACTION_READ_COMMITTED impedisce che
ci siano dirty-reads, ma consente unrepeatable e phantom reads;
Connection.TRANSACTION_READ_UNCOMMITTED
non
consente nessun tipo di dirty, unrepeatable e phantom reads;
Connection.TRANSACTION_REPEATABLE_READ consente solo
phantom reads;
Connection.TRANSACTION_SERIALIZABLE
sono serializzabili.
le
transazioni
76 di 182
Transazioni: riassunto & considerazioni
L'inizio di una transazione deve essere eplicitato a livello di
connessione (Connection) disabilitando la modalità di
auto-commit.
Tutte le operazioni eseguite tramite uno Statement dopo
aver disabilitato l'auto-commit fanno parte della
transazione.
La fine di una transazione deve forzare un esplicito commit
o rollback sulla connessione.
Una volta terminata la transazione è necessario riabilitare
l'auto-commit, altrimenti le istruzioni succesive faranno
parte di una nuova transazione (il driver non ri-abilita da
solo l'auto-commit!).
77 di 182
JDBC:
DataSource
78 di 182
DataSource
Le API JDBC 2 introducono nel package javax.sql l'interfaccia
DataSource che si comporta come un wrapper attorno alla
connettività di un un database.
In sostanza un DataSource è un'oggetto che contiene tutte le
informazioni che servono per la connettività verso la sorgente dati
(database) quali URL, username, password, auto-commit mode, etc.
Lo scopo dei DataSource è quello di disaccoppiare l'impostazione
dei parametri di connettività (tipicamente amministrativi) dal loro
utilizzo (tipicamente applicativo).
Diverse applicazioni possono condividere la stessa DataSource (ad
esempio tramite JNDI); una modifica nel DataSource (ad esempio
modifica all'URL) non necessita nessun intervento sulle applicazioni
che lo utilizzano.
79 di 182
ConnectionPoolDataSource
Un
tipo
particolare
di
sorgente
dati
è
il
ConnectionPoolDataSource che consente di gestire le
connessioni in pool.
L'idea è quella di mantenere le connessioni al database in una
cache, in modo da renderle disponibili a diversi componenti
man mano che vengono richieste. Non venendo aperte/chiuse
di continuo, le connessioni vengono erogate con tempi di
risposta più bassi rispetto all'approccio classico.
L'utilizzo delle sorgenti dati con pool richiede però qualche
passaggio in più rispetto all'uso delle sorgenti dati semplici.
Viene comunque garantito il disaccoppiamento fra la parte
amministrativa e quella applicativa.
80 di 182
DataSource & PostgreSQL
I driver JDBC di PostgreSQL mettono a disposizione due tipi
principali
di
DataSource
(contenute
nel
package
org.postgresql.ds):
PGSimpleDataSource un DataSource senza alcun tipo di
pooling. Implementa javax.sql.DataSource e dispone di
un metodo getConnection() che fornisce la connessione
al database. Ad esempio:
DataSource dataSource = new PGSimpleDataSource();
...
Connection connection = dataSource.getConnection();
81 di 182
DataSource & PostgreSQL
PGPoolingDataSource un DataSource con capacità di
pooling
delle
connessioni.
Implementa
javax.sql.ConnectionPoolDataSource e mette a
disposizione un metodo getPooledConnection() che
fornisce un oggetto javax.sql.PooledConnection, al
quale si può richiedere la connessione tramite
getConnection(). Ad esempio:
ConnectionPoolDataSource dataSource = new PGConnectionPoolDataSource();
...
PooledConnection pooledConnection = dataSource.getPooledConnection();
Connection connection = pooledConnection.getConnection();
82 di 182
Impostazione delle proprietà di una sorgente dati
Le proprietà delle sorgenti dati vengono impostati tramite metodi set
(e lette dai relativi metodi get secondo le specifiche Java Beans).
Solitamente gli ambienti server mettono a disposizione dei file di
configurazione (es. XML) che consentono di specificare le varie
proprietà. L'ambiente container (es. Tomcat) si farà poi carico di
leggere tale file di configurazione e di impostare le proprietà di
connessione nella sorgente dati.
serverName
Indirizzo IP o nome del server database
databaseName
Nome del database cui collegarsi
portNumber
Porta a cui collegarsi tramite TCP/IP
user
Utente da usare per la connessione
password
Password per l'utente di cui sopra
initialConnections Numero di connessioni da creare all'avvio
maxConnections
Massimo numero di connessioni istanziabili
83 di 182
Esempio di uso di DataSource
// creazione di un data source per PostgreSQL
PGConnectionPoolDataSource dataSource = new org.postgresql.ds.PGConnectionPoolDataSource();
// impostazione dei parametri di connessione
dataSource.setDatabaseName("pgdaydb");
dataSource.setUser("luca"); dataSource.setPassword(null);
dataSource.setServerName("localhost"); dataSource.setDefaultAutoCommit(true);
// ora il datasource andrebbe esportato e reso disponibile
// ad altre applicazioni, ad esempio tramite JNDI
...
// prelevo la sorgenti dati
ConnectionPoolDataSource source = (ConnectionPoolDataSource) dataSource;
// oppure
// PooledConnection pooledConnection = // source.getPooledConnection();
84 di 182
Spring
La libreria Spring fornisce un sottoinsieme di
classi di utilità per la connessione a database e la
realizzazione di DAO.
<! il template jdbc che deve essere inizializzato con una datasource >
<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
<constructorarg>
<ref bean="datasource" />
</constructorarg>
</bean>
<! inmpostazione della datasource >
<bean id="datasource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="org.postgresql.Driver" />
<property name="url" value="jdbc:postgresql://192.168.1.2/hrpmdb" />
<property name="username" value="hrpm" />
<property name="password" value="HrPm" />
</bean>
85 di 182
Spring lato applicativo
Lato applicativo occorre ottenere il jdbctemplate e
usare uno dei suoi metodi per effettuare le query.
// insert the address in the database
this.jdbcTemplate.update( this.getInsertQuery(), toInsert.getPrimaryKey(), toInsert.getStreet(), toInsert.getCity(), toInsert.getCountry(), toInsert.getState(), toInsert.getPhone(), toInsert.getZipCode(), toInsert.getFax() );
86 di 182
Java Transaction API
87 di 182
Java Transaction API (JTA)
La Java Transaction API (JTA) è un insieme di interfaccie e
classi che forniscono una astrazione verso un sistema di
transazioni distribuite.
Una transazione distribuita è una transazione che coinvolge
più risorse (database) allo stesso momento. La necessità di
mantenere coerenti le risorse (database) richiede protocolli
appositi per la decisione di commit/rollback globale.
La JTA si appoggia su una implementazione specifica del
server, chiamata Java Transaction Service (JTS). Il JTS è
responsabile di implementare il Transaction Manager, che è il
componente che prende la decisione globale sul
commit/rollback.
88 di 182
Transazioni distribuite in Java
Java Application
User
UserTransaction
Transaction
Interface
Interface
Transaction
TransactionManager
Manager
JDBC
JDBCDriver
Driver
Application Server
Database
Engine
Database
Engine
89 di 182
Transazioni distribuite in Java
L'interfaccia
javax.transaction.UserTransaction
consente di definire i confini di una transazione distribuita,
ossia quale sezione di codice debba essere
eseguito come transazione. La sua implementazione
dipende dal container che si sta utilizzando.
L'interfaccia
javax.transaction.TransactionManager
consente la gestione delle risorse di transazione al
container.
L'interfaccia
javax.transaction.xa.XAResource
rappresenta una risorsa XA da gestire.
90 di 182
Transazioni distribuite: Commit a due
fasi
Il protocollo di commit a due fasi (Two Phase Commit) è un algoritmo
distribuito che consente a tutti i nodi che partecipano alla transazione di
accordarsi all'unisono per un commit o un rollback.
(fase 1: pre-commit) Il coordinatore invia un query-to-commit a tutti i partecipanti.
Ogni partecipante effettua le operazioni, aggiorna i propri log (undo e redo) e invia un
messaggio di commit o rollback al coordinatore.
(fase 2: commit) Quando il coordinatore ha tutti i messaggi dei partecipanti prende la
decisione:
se tutti hanno inviato un commit il coordinatore conferma il commit ai
partecipanti che rendono permanenti le modifiche e inviano un
acknowledgement. Il coordinatore chiude la transazione quando riceve tutti gli
acknoweldgement.
se almeno un partecipante ha inviato un rollback il coordinatore invia un
rollback ai partecipanti, che annullano la loro transazione locale e confermano
il rollback al coordinatore.
91 di 182
Risorse X/Open CAE
X/Open CAE specifica gli oggetti e le interfaccie da usare
nelle transazioni distribuite (Distributed Transaction
Processing: the XA specification): definisce cosa un gestore
di risorse debba fare per supportare le transazioni distribuite.
Il supporto XA del driver è fondamentale per consentire l'uso
con transazioni distribuite.
Il driver JDBC di PostgreSQL supporta XA dalla versione 8.1,
anche se senza supporto per il transaction interleaving
(capacità di usare la stessa connessione per differenti
transazioni contemporanee).
92 di 182
JTA & Driver JDBC
Nonostante il Transaction Manager sia il
componente più importante, il driver JDBC deve
fornire supporto a XADatasource, XAConnection e
XAResource.
Le classi di più alto livello JTA, quali ad esempio
UserTransaction e TransactionManager non sono
nello scope di un driver JDBC quanto di un
application server.
93 di 182
Identificazione di una transazione
Una transazione è identificata da un Transaction ID
composto da tre parti fondamentali:
format ID: specifica il naming schema delle
transazioni (es. OSI CCR – Commitment,
Concurrency e Recovery).
branch qualifier: un branch rappresenta una singola
richiesta ad un resource manager.
global transaction id: un identificativo globale della
transazione in tutto il sistema.
L'implementazione di un transaction
dipende dal container/sistema utilizzato.
id (javax.transaction.xa.Xid)
94 di 182
Creazione di uno Xid
public class PgDayXid implements Xid{
// Il formatID specifica quale specifica si sta usando. // Se vale 0 allora si sta usando la specifica OSICCR // (OSICommitment, Concurrency and Recovery).
// Se vale 1 allora l'Xid non è valido, // mentre se è superiore a zero allora indica // una specifica proprietaria.
protected int formatID = 0;
// identificativo globale della transazione corrente. (064 bytes)
protected byte[] globalTransactionId = null;
// identificativo del ramo della transazione corrente. (064 bytes)
protected byte[] branchQualifier = null;
public byte[] getBranchQualifier() { return this.branchQualifier; }
public int getFormatId() { return this.formatID; }
public byte[] getGlobalTransactionId() { return this.globalTransactionId; }
95 di 182
Creazione di uno Xid
public void setGlobalTransactionId(byte[] gtid){
// tengo conto solo dei primi 64 bytes...
if( gtid != null && gtid.length > 64 ){
System.arraycopy( gtid, 0, this.globalTransactionId, 0, 64 );
}
else
this.globalTransactionId = gtid;
}
public void setBranchQualifier(byte[] bq){
...
}
public void setFormatId(int id){
...
}
}
96 di 182
Utilizzo di JTA
public static void main(String[] args) throws Exception {
// 1) creazione di un datasource agganciato al database
PGXADataSource dataSource = new PGXADataSource();
dataSource.setDatabaseName("pgday");
// nome del database
dataSource.setUser("luca");
// username
dataSource.setPassword("fluca");
// password dell'utente
dataSource.setServerName("localhost");
// indirizzo di connessione
// del database
// 2) ottengo una connessione al database
System.out.println("Tentativo di connessione al database...");
XAConnection connection = dataSource.getXAConnection();
System.out.println("Connesso!");
// 3) ottengo una risorsa per proteggere la transazione
XAResource resource = connection.getXAResource();
97 di 182
Utilizzo di JTA
// 4) devo avere un id della transazione che sto per usare
PgDayXid identifier = new PgDayXid();
identifier.setBranchQualifier(
new byte[] {0x01, 0x02, 0x03, 0x04, 0x05});
identifier.setGlobalTransactionId(
new byte[] {0x05, 0x04, 0x03, 0x02, 0x01});
identifier.setFormatId(100);
// 5) eseguo la transazione
try{
// 6) inizio della transazione
resource.start(identifier, XAResource.TMNOFLAGS);
// 7) esecuzione di operazioni JDBC
Connection jdbcConnection = connection.getConnection();
jdbcConnection.setAutoCommit(false); // bug del driver!
Statement statement = jdbcConnection.createStatement();
String sql = "INSERT INTO corso(corsoID, descrizione)
VALUES('XA1', 'Corso su JTA')";
int inserted = statement.executeUpdate(sql);
System.out.println("Sono state inserite " + inserted + " righe");
98 di 182
Utilizzo di JTA
// 8) ho terminato la transazione
resource.end(identifier, XAResource.TMSUCCESS);
// 9) controllo se il transaction manager consente il commit
// (fase di precommit)
int commit = resource.prepare(identifier); System.out.println("Valore del prepare " + commit);
if( commit == XAResource.XA_OK )
// commit definitivo
resource.commit(identifier, // identificativo transazione
false); // false = commit 2 fasi
else
resource.rollback(identifier);
}catch(XAException e){
e.printStackTrace();
}
}
99 di 182
Sospensione di una transazione
E' possibile sospendere una transazione distribuita
per dare modo al processo corrente di eseguire
operazioni locali.
E' necessario terminare la transazione distribuita e
avviarla nuovamente specificando come flag
rispettivamente TMSUSPEND e TMRESUME.
// 8) sospensione della transazione distribuita
resource.end(identifier, XAResource.TMSUSPEND);
// 8 bis) effettuo degli statement fuori dalla transazione // distribuita usando lo stesso oggetto Statement
statement.executeUpdare(...);
// 8 tris) riprendo la transazione distribuita
resource.start(identifier, XAResource.TMRESUME);
100 di 182
JDBC & SSL
101 di 182
Connessioni SSL
PostgreSQL supporta nativamente le connessioni tramite
SSL/TLS da parte dei client (si veda il capitolo 16 del manuale).
Solitamente il server PostgreSQL accetta sia connessioni in
chiaro che cifrate sulla stessa porta, negoziando dinamicamente il
tipo di connessione ricevuta.
Una connessione in chiaro invia i pacchetti (es. le query e i risultati)
senza cifrarli, e quindi questi sono osservabili sulla rete. Una
connessione SSL utilizza uno schema di cifratura per rendere
illeggibili da terzi i pacchetti in transito.
102 di 182
Connessioni SSL: impostazioni del server
Il server deve essere stato compilato con il supporto per SSL, e i
certificati devono essere stati generati e si devono trovare nella
directory $PGDATA.
103 di 182
Connessioni SSL: test
Per verificare il funzionamento del supporto SSL è possibile usare il
client da riga di comando.
Di default viene usata
una connessione in
chiaro
La suite di cifratura è
disponibile
(connessione esplicita a
localhost)
104 di 182
Java & SSL
Ci sono due modi principali di utilizzo di SSL nelle connessioni a
PostgreSQL:
connessione verificata: il certificato del server è stato
correttamente importato nel keystore (personale o di sistema) di
Java, ad indicare che il certificato è noto e corretto. In tal caso, il
driver JDBC di PostgreSQL effettua i controlli necessari per
validare il certificato ed evitare attacchi man-in-the-middle.
connessione non verificata: non è possibile importare il
certificato nel keystore, e quindi ci si fida al volo (con i rischi che
ne derivano) del certificato presentato dal server. In questo caso
occorre usare una socket factory messa a disposizione dal driver
JDBC di PostgreSQL.
105 di 182
Connessione verificata
Il driver JDBC di PostgreSQL si occupa di tutta la parte di
scambio di chiavi e connessione, ma occorre importare il
certificato del server nel keystore:
(1) il certificato del server deve essere tradotto in una forma che
keytool può comprendere. A tal fine lo si converte come file DER
(ASN1-DER; formato senza header) dal formato PEM (standard
per openssl, presenta un header testuale).
106 di 182
(2) il certificato deve essere importato nel keystore (in questo
caso privato dell'utente). Al certificato viene associata l'alias
pgday, che rappresenta una sorta di username (in realtà è il
proprietario del certificato). Il keystore generato, essendo usato
per la verifica di un'identità e non strettamente per la cifratura,
viene anche denominato trustore.
107 di 182
(3) l'URL di connessione deve contenere il parametro ssl=true,
al fine di indicare al driver di usare la connessione SSL (viene
usata la factory socket di default).
Connection connection = DriverManager.getConnection(
"jdbc:postgresql://localhost/pgday?loglevel=2&ssl=true", "luca", "fluca");
(4) occorre specificare come parametri alla JVM quale
keystore usare e quale password.
[luca@fluca:~]$ java Djavax.net.ssl.trustStore=$HOME/keystore Djavax.net.ssl.trustStorePassword=aglets it.pgday.lferrari.PgJDBC1
108 di 182
La connessione impiega qualche secondo per essere
convertita da normale a cifrata. Il traffico in circolazione
non è più in chiaro.
109 di 182
Connessione non verificata
E' possible stabilire una connessione SSL senza aver verificato
(importato) il certificato del server. A tal scopo è sufficiente
impostare la factory di socket SSL come parametro della URL di
connessione a org.postgresql.ssl.NonValidatingFactory. Non è più
necessario specificare il keystore e la sua password.
Connection connection = DriverManager.getConnection(
"jdbc:postgresql://localhost/pgday?loglevel=2&ssl=true
&sslfactory=org.postgresql.ssl.NonValidatingFactory",
"luca", "fluca");
[luca@fluca:~]$ java it.pgday.lferrari.PgJDBC1
110 di 182
org.postgresql.Driver
111 di 182
Registrazione del Driver PostgreSQL
Il Driver si auto-registra in modo statico richiamando il
metodo (static) registerDriver di DriverManager.
La registrazione statica anziché nel costruttore del Driver
stesso (come molti alti driver fanno) impedisce una
registrazione multipla dello stesso driver all'interno della
JVM.
static {
static {
try{
try{
java.sql.DriverManager.registerDriver(new Driver());
java.sql.DriverManager.registerDriver(new Driver());
}
}
catch (SQLException e)
catch (SQLException e)
{ e.printStackTrace(); }
{ e.printStackTrace(); }
}
// org.postgresql.Driver
}
112 di 182
Come il DriverManager sceglie il Driver appropriato...
private static Connection getConnection(String url, Properties info, private static Connection getConnection(String url, Properties info, ClassLoader callerCL) throws SQLException {
ClassLoader callerCL) throws SQLException {
java.util.Vector drivers = null;
java.util.Vector drivers = null;
...
...
synchronized (DriverManager.class){ synchronized (DriverManager.class){ drivers = readDrivers; drivers = readDrivers; }
}
...
...
SQLException reason = null;
SQLException reason = null;
for (int i = 0; i < drivers.size(); i++) {
for (int i = 0; i < drivers.size(); i++) {
DriverInfo di = (DriverInfo)drivers.elementAt(i); DriverInfo di = (DriverInfo)drivers.elementAt(i); Connection result = di.driver.connect(url, info);
Connection result = di.driver.connect(url, info);
if (result != null) {
if (result != null) {
class DriverInfo {
return (result);
class DriverInfo {
return (result);
Driver driver;
} Driver driver;
} Class driverClass;
// codice di gestione Class driverClass;
// codice di gestione String driverClassName;
// errori ...
String driverClassName;
// errori ...
}
// java.sql.DriverManager
}}
}
...
...
}}
113 di 182
connect(..)
Il metodo connect(..) del driver PostgreSQL effettua la
connessione effettiva al database:
si verifica che l'URL di connessione sia gestibile ed appropriato
tramite il metodo acceptsURL(..);

se non è stato specificato un timeout di login viene tentata la
connessione direttamente nel thread chiamante (metodo
makeConnection(..));

se è stato specificato un timeout di login viene creato un nuovo
thread (ConnectionThread), che cercherà di effettuare la
connessione (metodo run()) mentre il thread chiamante resterà
in attesa per un tempo pari al timeout specificato (metodo
getResult(..)).

114 di 182
connect(..)
public java.sql.Connection connect(String url, Properties info) public java.sql.Connection connect(String url, Properties info) throws SQLException {
throws SQLException {
...
...
try { // se non ho nessun timeout tento la connessione
try { // se non ho nessun timeout tento la connessione
// direttamente (opzione di default)
// direttamente (opzione di default)
long timeout = timeout(props);
long timeout = timeout(props);
if (timeout <= 0)
if (timeout <= 0)
return makeConnection(url, props);
return makeConnection(url, props);
// tento la connessione tramite un altro thread
// tento la connessione tramite un altro thread
ConnectThread ct = new ConnectThread(url, props);
ConnectThread ct = new ConnectThread(url, props);
new Thread(ct, new Thread(ct, "PostgreSQL JDBC driver connection thread").start();
"PostgreSQL JDBC driver connection thread").start();
return ct.getResult(timeout);
return ct.getResult(timeout);
} catch (PSQLException ex1) {
} catch (PSQLException ex1) {
throw ex1;
throw ex1;
} catch (Exception ex2) {
} catch (Exception ex2) {
throw new PSQLException(...);
}
}
}}
115 di 182
PGStream: un oggetto magico
PGStream rappresenta un wrapper attorno
connessione verso il database PostgreSQL.
ad
una
Esso
contiene
un
riferimento
ad
un
oggetto
java.net.Socket che rappresenta la connessione al
database e agli stream per la lettura e la scrittura dei dati su
tale socket (sottoclassi specifiche di OutpuStream e
InputStream).
PGStream mette a disposizione dei metodi di utilità per la
scrittura/lettura di byte, interi (2,4 byte), char, stringhe, etc.
che vengono usati per l'invio di informazioni secondo il
protocollo di comunicazione V2 o V3.
116 di 182
Interfacce particolari
QueryExecutor: gestisce i messaggi specifici di una
versione di protocollo (es. V3) per l'esecuzione di query. Una
implmentazione
è
ad
esempio
org.postgresql.core.v3.QueryExecutorImpl.
ResultHandler: gestisce la costruzione progressiva di
ResultSet (aggiunge una tupla man mano che viene ricevuta
dalla rete), warning ed errori.
SimpleQuery: gestione dei dati di una query singola.
117 di 182
Comunicazione
FrontEnd-BackEnd
La comunicazione fra il lato applicativo (FrontEnd – driver) e il
server (BackEnd) avviene tramite l'uso di un protocollo a scambio
di messaggi.
Il protocollo, giunto alla sua terza revisione (PostgreSQL >= 7.4)
viene comunemente denominato protocollo V3.
118 di 182
Protocollo V3:
formato dei messaggi
Un messaggio è un pacchetto contenente diversi
byte rappresentati l'informazione.
message_type
(1 byte)
length
(4 bytes)
content
(length – 4 bytes)
il primo byte del messaggio identifica il
tipo del messaggio stesso
i successivi quattro byte specificano la
lunghezza del messaggio stesso (incluso il
dato di lunghezza stesso)
i rimanenti byte rappresentano
contenuto del messaggio
il
119 di 182
PreparedStatement vs Portal
La fase di parse genera un PreparedStatement, ossia
un oggetto che rappresenta l'interpretazione lessicale di
una query.
Tale oggetto subirà poi il bind dei parametri venendo
promosso in un Portal, un oggetto pronto ad eseguire la
query.
Sostanzialmente un Portal è un handle per una query
pronta da eseguire o che sta eseguendo, una sorta di
cursore (che funziona anche per query non SELECT).
Un portale puo' essere identificato da un nome, oppure
rimanere unnamed se si usa il portale di default.
120 di 182
Protocollo V3:
Simple & Extended Query
Il protocollo prevede due modalità principali di
funzionamento:
Simple Query: viene inviato un messaggio con la
query e questa viene immediatamente eseguita; i
risultati vengono poi inviati al frontend.
Extended Query: viene inviata la query ma non
viene eseguita immediatamente. In una fase
successiva si fa il bind dei parametri della query, si
esegue la query e si inviano i risultati al frontend.
Simple Query : Statement = Extended Query : PreparedStatement
121 di 182
Simple Query
BackEnd
FrontEnd
Query
contiene la string SQL
della query da eseguire
RowDescription
indica il layout delle colonne
ritornate dalla query
RowData
dati di una singola riga
RowData
RowData
ReadyForQuery
indica che il backend è pronto
ad accettare una nuova query
122 di 182
Extended Query
BackEnd
FrontEnd
Parse (stringa SQL, [nome prepared statement, nome portale])
ParseComplete
Bind (lista parametri, [nome prepared statement, nome portale])
BindComplete
Execute ([nome portale])
RowData
dati di una singola riga
RowData
RowData
Sync
sincronizzazione per errori
ReadyForQuery
il backend è pronto
123 di 182
Query: overview
Viene creato un oggetto Statement dal
Connection corrente. Tipicamente si passa
attraverso AbstractJdbc2Connection, che
richiama il tipo di connessione corretto (es.
Jdbc4Connection).
Il metodo executeQuery(..) viene sempre
richiamato su AbstractJdbc2Statement,
che mediante QueryExecutor ottiene un
oggetto SimpleQuery che implementa il
protocollo di comunicazione FrontEnd e
BackEnd opportuno (es. v3).
124 di 182
Query: overview
Il
metodo
execute(..)
di
AbstractJdbc2Statement accetta l'oggetto
query da eseguire e richiama il metodo
execute(..) sul QueryExecutor. Al metodo
viene
anche
passato
un
oggetto
ResultHandler che si occupa di gestire
risultati (ResultSet), errori e warning.
Il QueryExecutor invia i messaggi necessari
al server, in particolare tramite il metodo
sendQuery(..) e sendOneQuery(..) invia
la query da eseguire in formato testuale.
125 di 182
Query: overview
Il QueryExecutor processa la risposta del server tramite
processResult(..). Questo metodo utilizza l'oggetto
PGStream per leggere i messaggi in arrivo dal server.
Viene usato un meccanismo ad eventi: a seconda del
messaggio letto viene richiamato un metodo opportuno sul
ResultHandler. In questo modo l'handler può, ad
esempio, memorizzare le tuple man mano che vengono
lette.
Si richiede al ResultHandler di restituire il ResultSet.
Questo viene ritornato indietro lungo lo stack fino al lato
applicativo.
126 di 182
Creazione di uno Statement
public java.sql.Statement createStatement() throws SQLException {
public java.sql.Statement createStatement() throws SQLException {
// crea uno statement per un Resultset classico
// crea uno statement per un Resultset classico
return createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY, return createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY, java.sql.ResultSet.CONCUR_READ_ONLY);
java.sql.ResultSet.CONCUR_READ_ONLY);
}}
// org.postgresql.jdbc2.AbstractJdbc2Connection
// org.postgresql.jdbc2.AbstractJdbc2Connection
public java.sql.Statement createStatement(int resultSetType, public java.sql.Statement createStatement(int resultSetType, int resultSetConcurrency, int resultSetHoldability) int resultSetConcurrency, int resultSetHoldability) throws SQLException {
// creazione di uno statement di livello 4
// creazione di uno statement di livello 4
Jdbc4Statement s = new Jdbc4Statement(this, resultSetType, Jdbc4Statement s = new Jdbc4Statement(this, resultSetType, resultSetConcurrency, resultSetHoldability);
resultSetConcurrency, resultSetHoldability);
s.setPrepareThreshold(getPrepareThreshold());
s.setPrepareThreshold(getPrepareThreshold());
return s;
return s;
}}
// org.postgresql.jdbc4.Jdbc4Connection
// org.postgresql.jdbc4.Jdbc4Connection
La creazione di uno Statement implica ancora una volta il passaggio fra le classi dei vari
livelli JDBC. In particolare si parte dal livello 2 (il minimo) e si arriva fino al livello 4 creando
un Jdbc4Statement.
127 di 182
Esecuzione di una query
public ResultSet executeQuery(String p_sql) throws SQLException {
public ResultSet executeQuery(String p_sql) throws SQLException {
// se ho una query preprata (PreparedStament) non processare
// se ho una query preprata (PreparedStament) non processare
// un'altra query SQL (p_sql)
// un'altra query SQL (p_sql)
if (preparedQuery != null)
if (preparedQuery != null)
// eseguo la query specificata
// eseguo la query specificata
if (!executeWithFlags(p_sql, 0))
if (!executeWithFlags(p_sql, 0))
// sono stati ritornati troppi result set in una sola volta
// sono stati ritornati troppi result set in una sola volta
if (result.getNext() != null)
return (ResultSet)result.getResultSet();
return (ResultSet)result.getResultSet();
}}
// org.postgresql.jdbc2.AbstractJdbc2Statement
Il metodo fondamentale per l'esecuzione di una query è executeWithFlags. Mediante
tale metodo viene creato un oggetto SimpleQuery che si occuperà dello scambio di
messaggi con il backend per il protocollo relativo.
128 di 182
public boolean executeWithFlags(String p_sql, int flags) public boolean executeWithFlags(String p_sql, int flags) throws SQLException {
// controlla se lo statement è chiuso (nel caso solleva // controlla se lo statement è chiuso (nel caso solleva // una eccezione)
// una eccezione)
checkClosed();
checkClosed();
// effettua alcune sostituzione nella query (es. escaping)
// effettua alcune sostituzione nella query (es. escaping)
p_sql = replaceProcessing(p_sql);
p_sql = replaceProcessing(p_sql);
Query simpleQuery = Query simpleQuery = connection.getQueryExecutor().createSimpleQuery(p_sql);
connection.getQueryExecutor().createSimpleQuery(p_sql);
execute(simpleQuery, null, QueryExecutor.QUERY_ONESHOT | flags);
this.lastSimpleQuery = simpleQuery;
// result è un tipo ResultWrapper, che contiene // result è un tipo ResultWrapper, che contiene // anche il ResultSet
// anche il ResultSet
return (result != null && result.getResultSet() != null);
}}
public Query createSimpleQuery(String sql) {
public Query createSimpleQuery(String sql) {
return parseQuery(sql, false);
return parseQuery(sql, false);
}}
// org.postgresql.core.v3.QueryExecutorImpl
129 di 182
protected void execute(Query queryToExecute, protected void execute(Query queryToExecute, ParameterList queryParameters, int flags) throws SQLException {
ParameterList queryParameters, int flags) throws SQLException {
// chiusura di query precedenti e pulizia di warning ed errori
// chiusura di query precedenti e pulizia di warning ed errori
// che potevano provenire da query precedenti
// che potevano provenire da query precedenti
StatementResultHandler handler = new StatementResultHandler();
StatementResultHandler handler = new StatementResultHandler();
result = null;
result = null;
connection.getQueryExecutor().execute(queryToExecute,
connection.getQueryExecutor().execute(queryToExecute,
queryParameters,
queryParameters,
handler,
handler,
maxrows,
maxrows,
fetchSize,
fetchSize,
flags);
flags);
result = firstUnclosedResult = handler.getResults();
result = firstUnclosedResult = handler.getResults();
}}
Si prepara un handler per il risultato ed eventuali errori e si passa la query e l'handler al
metodo execute(..) del QueryExecutor (la sua implementazione per il protocollo V3)
affinché gestisca i messaggi.
130 di 182
(lettura risultati)
protected void processResults(ResultHandler handler, int flags) protected void processResults(ResultHandler handler, int flags) throws IOException {
throws IOException {
Vector tuples = new Vector(); Field[] fields = null;
Vector tuples = new Vector(); Field[] fields = null;
...
...
while (!endQuery) {
while (!endQuery) {
c = pgStream.ReceiveChar();
c = pgStream.ReceiveChar();
switch (c){
switch (c){
case 'D': // messaggio di tipo DataRow
case 'D': // messaggio di tipo DataRow
Object tuple = null;
Object tuple = null;
try {
try {
tuple = pgStream.ReceiveTupleV3();
tuple = pgStream.ReceiveTupleV3();
} catch(OutOfMemoryError oome) { ... }
} catch(OutOfMemoryError oome) { ... }
if (!noResults)
if (!noResults)
tuples.addElement(tuple);
tuples.addElement(tuple);
break;
break;
...
...
131 di 182
(lettura risultati)
case 'C': // command status (fine esecuzione execute)
case 'C': // command status (fine esecuzione execute)
String status = receiveCommandStatus();
...
...
if (fields != null || tuples != null) { if (fields != null || tuples != null) { handler.handleResultRows(currentQuery, fields, tuples, null);
handler.handleResultRows(currentQuery, fields, tuples, null);
fields = null; tuples = null;
}
}
else
else
interpretCommandStatus(status, handler);
...
...
break;
break;
case 'Z': // ready for query
case 'Z': // ready for query
receiveRFQ();
receiveRFQ();
endQuery = true; // termina il ciclo while
endQuery = true; // termina il ciclo while
// pulizia degli oggetti in memoria e delle code
// pulizia degli oggetti in memoria e delle code
...
...
break;
break;
...
...
}
}
}
}
}}
132 di 182
Query: traffico di rete
Analizzando il traffico di rete con uno sniffer è possibile vedere i singoli messaggi
inviati da e per il server. Nell'esempio qui sopra si nota il messaggio di Parse,
con la query inviata, seguito da vari messaggi uno dei quali Execute.
133 di 182
In questo caso si vede il messaggio RowDescription che precede una serie di
messaggi DataRow, ciascuno con indicazione del numero, lunghezza e valore
delle colonne.
134 di 182
Messaggio Parse contenente la
query e il nome dello statement
di riferimento sul server (null).
Il server invia un
RowDescription e di seguito
tutte le righe tramite una serie di
DataRow.
Il server invia i messaggi di
chiusura, fra i quali
ReadyForQuery.
135 di 182
Esecuzione di una query parametrica
statement2.setInt(1, corsoPK); statement2.setInt(1, corsoPK); // lato applicativo
// lato applicativo
La fase di bind in memoria prevede che il parametro sia associato alla sua posiziona nella
query (index), al suo valore (rappresentato come stringa) e al suo tipo (OID) affinché il
BackEnd possa capire come trattare il dato stesso.
I parametri sono contenuti in oggetti che implementano ParameterList a seconda del
protocollo utilizzato (ad es. V3ParameterList).
public void setInt(int parameterIndex, int x) throws SQLException {
public void setInt(int parameterIndex, int x) throws SQLException {
checkClosed(); checkClosed(); bindLiteral(parameterIndex, Integer.toString(x), Oid.INT4);
bindLiteral(parameterIndex, Integer.toString(x), Oid.INT4);
}}
private void bindLiteral(int paramIndex,String s,int oid) private void bindLiteral(int paramIndex,String s,int oid) throws SQLException {
if(adjustIndex)
if(adjustIndex)
paramIndex;
paramIndex;
// registro il parametro in un contenitore V3ParameterList
// registro il parametro in un contenitore V3ParameterList
preparedParameters.setLiteralParameter(paramIndex, s, oid);
preparedParameters.setLiteralParameter(paramIndex, s, oid);
} // org.postgresql.jdbc2.AbstractJdbc2Statement
136 di 182
Il metodo executeQuery(), invocato dopo il bind dei parametri, richiama il metodo
executeWithFlags(..) già visto in precedenza e usato anche per query non
parametriche.
Ripercorrendo
lo
stack
di
chiamata
si
giunge
a
QueryExecutor.execute(..) che questa volta ha impostato i parametri della query. Da
qui si passa poi a QueryExecutor.sendOneQuery(..) che provvede a sostituire ad ogni
parametro (indicato con ?) un $n (con n valore della posizione partendo da 1). In coda alla
query compare poi l'array degli OID dei tipi dei parametri.
public java.sql.ResultSet executeQuery() throws SQLException {
public java.sql.ResultSet executeQuery() throws SQLException {
if (!executeWithFlags(0))
if (!executeWithFlags(0))
return (ResultSet) result.getResultSet();
return (ResultSet) result.getResultSet();
FE=> Parse(stmt=null,query="SELECT cognome, nome FE=> Parse(stmt=null,query="SELECT cognome, nome FROM partecipante WHERE corsoPK=$1",oids={23})
FROM partecipante WHERE corsoPK=$1",oids={23})
137 di 182
private void sendBind(SimpleQuery query, SimpleParameterList params, private void sendBind(SimpleQuery query, SimpleParameterList params, Portal portal) throws IOException {
Portal portal) throws IOException {
// informazioni su portale e statement (se esistono)
// informazioni su portale e statement (se esistono)
String statementName = query.getStatementName();
String statementName = query.getStatementName();
byte[] encodedStatementName = query.getEncodedStatementName();
byte[] encodedStatementName = query.getEncodedStatementName();
byte[] encodedPortalName = (portal == null ? null : byte[] encodedPortalName = (portal == null ? null : portal.getEncodedPortalName());
portal.getEncodedPortalName());
...
...
pgStream.SendChar('B'); pgStream.SendChar('B'); // messaggio Bind
// messaggio Bind
pgStream.SendInteger4((int)encodedSize); // dimensione messaggio
pgStream.SendInteger4((int)encodedSize); // dimensione messaggio
if (encodedPortalName != null)
// eventuale portale
if (encodedPortalName != null)
// eventuale portale
pgStream.Send(encodedPortalName); pgStream.Send(encodedPortalName); pgStream.SendChar(0); pgStream.SendChar(0); if (encodedStatementName != null)
if (encodedStatementName != null)
pgStream.Send(encodedStatementName); pgStream.Send(encodedStatementName); // eventuale statement
// eventuale statement
pgStream.SendChar(0); pgStream.SendChar(0); ...
...
138 di 182
// invio tipo e numero dei parametri
// invio tipo e numero dei parametri
for (int i = 1; i <= params.getParameterCount(); ++i)
for (int i = 1; i <= params.getParameterCount(); ++i)
pgStream.SendInteger2(params.isBinary(i) ? 1 : 0); pgStream.SendInteger2(params.isBinary(i) ? 1 : 0); pgStream.SendInteger2(params.getParameterCount()); pgStream.SendInteger2(params.getParameterCount()); ...
...
for (int i = 1; i <= params.getParameterCount(); ++i) {
for (int i = 1; i <= params.getParameterCount(); ++i) {
if (params.isNull(i))
if (params.isNull(i))
pgStream.SendInteger4( 1); // dimensione 1 => NULL
pgStream.SendInteger4( 1); // dimensione 1 => NULL
else {
else {
// dimensione del parametro
// dimensione del parametro
pgStream.SendInteger4(params.getV3Length(i)); pgStream.SendInteger4(params.getV3Length(i)); try{ // valore del parametro
try{ // valore del parametro
params.writeV3Value(i, pgStream); params.writeV3Value(i, pgStream); }catch (PGBindException be) {
}catch (PGBindException be) {
bindException = be;
bindException = be;
}
}
}
}
}
}
...
...
} // org.postgresql.core.v3.QueryExecutorImpl
139 di 182
Esecuzione di INSERT/UPDATE
I passi fondamentali sono simili a quanto visto in precedenza:
si
deve
ottenere
(AbstractJdbc2Connection)
(AbstractJdbc2Statement);
dall'oggetto
uno
Connection
Statement
si richiede allo Statement (AbstractJdbc2Statement) di
eseguire
la
modifica
mediante
il
metodo
JDBC
executeUpdate(String sql);
si ottiene come valore di ritorno il numero di record modificati nella
base di dati (command status)
Il command status viene interpretato letteralmente, ossia dalla stringa di command
status inviata dal BackEnd si estraggono i valori ritornati dal server.
140 di 182
Esecuzione di un INSERT/UPDATE
public int executeUpdate(String p_sql) throws SQLException {
public int executeUpdate(String p_sql) throws SQLException {
...
...
// eseguo la query tramite il QueryExecutor
// eseguo la query tramite il QueryExecutor
// non mi aspetto risultati (QUERY_NO_RESULTS)
// non mi aspetto risultati (QUERY_NO_RESULTS)
if (executeWithFlags(p_sql, QueryExecutor.QUERY_NO_RESULTS))
if (executeWithFlags(p_sql, QueryExecutor.QUERY_NO_RESULTS))
// non dovrei avere alcun risultato
// non dovrei avere alcun risultato
// restituisco il numero di record aggiornati/inseriti
// restituisco il numero di record aggiornati/inseriti
return getUpdateCount();
return getUpdateCount();
} // org.postgresql.jdbc2.AsbtractJdbc2Statement
} // org.postgresql.jdbc2.AsbtractJdbc2Statement
public boolean executeWithFlags(String p_sql, int flags) public boolean executeWithFlags(String p_sql, int flags) throws SQLException {
Query simpleQuery = Query simpleQuery = connection.getQueryExecutor().createSimpleQuery(p_sql);
connection.getQueryExecutor().createSimpleQuery(p_sql);
}}
// org.postgresql.jdbc2.AsbtractJdbc2Statement
// org.postgresql.jdbc2.AsbtractJdbc2Statement
141 di 182
Esecuzione di un INSERT/UPDATE
protected void processResults(ResultHandler handler, int flags) protected void processResults(ResultHandler handler, int flags) throws IOException {
throws IOException {
.... .... case 'C': // Command Status (end of Execute)
case 'C': // Command Status (end of Execute)
// ottiene la stringa risultato dell'esecuzione della query
// ottiene la stringa risultato dell'esecuzione della query
// ad esempio INSERT 0 1 oppure UPDATE 1
// ad esempio INSERT 0 1 oppure UPDATE 1
if (fields != null || tuples != null){ if (fields != null || tuples != null){ // qui c'e' un ResultSet, quindi una select // qui c'e' un ResultSet, quindi una select handler.handleResultRows(currentQuery, fields, tuples, null);
handler.handleResultRows(currentQuery, fields, tuples, null);
}
}
else {
else {
// qui non c'e' ResultSet, quindi una scrittura sul DB
// qui non c'e' ResultSet, quindi una scrittura sul DB
}
}
...
...
142 di 182
Pl/Java
143 di 182
Installazione di Pl/Java
Pljava si basa su un modulo del kernel denominato
pljava.so; la versione base è compilata per architettura 32
bit e verso PostgreSQL 8.3. Per una corretta installazione
su piattaforme e database differenti occorre:
usare un JDK fra la versione 4 e 5 (non la 6 perché cambiano le API JDBC);
installare gli header per lo sviluppo di PostgreSQL della versione corrente (ad
esempio postgresqlserverdev8.4);
scaricare tramite CVS l'ultima versione dei sorgenti di Pl/Java;
verificare che JAVA_HOME e il PATH puntino al compilatore Java corretto;
lanciare la compilazione con il comando make.
144 di 182
Occorre poi apportare alcune modifiche a
postgresql.conf
affinché
il
server-cluster
postmaster possa caricare l'estensione Java:
dynamic_library_path = '$libdir:/sviluppo/java/pljava/org.postgresql.pljava/build/objs'
custom_variable_classes = 'pljava'
pljava.classpath='/sviluppo/java/pljava/org.postgresql.pljava/build
/pljava.jar'
145 di 182
Introduzione a Pl/Java
Pl/Java è una estensione di PostgreSQL per supportare il
linguaggio Java come linguaggio interno.
Pl/Java è simile, concettualmente, ad altri Pl/xxx come ad
esempio Pl/Perl. La differenza principale con altri linguaggi
è che, essendo Java compilato, non è possibile scrivere
direttamente codice Java all'interno del server, bensì si
deve istruire il server per richiamare del codice Java in
formato bytecode. In altre parole usare Pl/Java significa
sempre:
Scrivere del codice Java.
Scrivere del codice SQL per richiamare Java.
146 di 182
JNI?
Il backend PostgreSQL non è scritto in Java!
Occorre quindi trovare un modo per far dialogare
un pezzo di codice Java con il backend. Ci sono
due soluzioni possibili:
RPC
JNI
Pl/Java si basa su JNI per svariate ragioni,
principalmente:
Piu' semplice ed efficiente
Il codice Java risiede sul server, quindi è locale al
backend (non c'è necessità di usare chiamate
remote)
147 di 182
1 backend = 1 JVM ?
// backend.c
static void initializeJavaVM(void){
...
jstat = JNI_createVM(&s_javaVM, &vm_args);
...
}
Nel file backend.c, che inizializza il collegamento fra il backend vero e
proprio e Java, si ha che per ogni connessione viene avviata una JVM
tramite JNI.
In sostanza si ha una JVM per ogni connessione utente.
Ciò è coerente con il design di PostgreSQL che prevede un processo
(backend appunto) per ogni connessione utente, inoltre garantisce la
protezione dello spazio utente tramite l'astrazione dei processi e infine
consente di gestire la priorità dei processi stessi tramite gli strumenti del
sistema operativo (ps, nice, ...).
148 di 182
PlJava viene fornito con uno strumento (Java) per
l'installazione del supporto Java presso un
determinato database: deploy.jar. Occorre
eseguire questo programma Java (che richiede la
presenza del driver JDBC PostgreSQL) per installare
il supporto dinamico a Java nel database:
java org.postgresql.pljava.deploy.Deployer install database hrpmdb user postgres password postgres
Il programma provvede a creare le funzioni handler e lo
schema speciale sqlj nel database.
149 di 182
Vedere cosa succede dietro le quinte
E' bene abilitare il livello di log_min_messages a
debug3 per ottenere un po' di informazioni circa
l'utilizzo di Java nel server. Nei log si troveranno
messaggi circa la creazione dell'istanza della JVM
e il caricamento delle classi.
20100601 13:55:03 CEST DEBUG: find_in_dynamic_libpath: trying "/usr/lib/postgresql/8.4/lib/pljava"
20100601 13:55:03 CEST DEBUG: find_in_dynamic_libpath: trying "/sviluppo/java/pljava/org.postgresql.pljava/build/objs/pljava"
20100601 13:55:03 CEST DEBUG: find_in_dynamic_libpath: trying "/usr/lib/postgresql/8.4/lib/pljava.so"
20100601 13:55:03 CEST DEBUG: find_in_dynamic_libpath: trying "/sviluppo/java/pljava/org.postgresql.pljava/build/objs/pljava.so"
20100601 13:55:03 CEST DEBUG: Using integer_datetimes
20100601 13:55:03 CEST DEBUG: Added JVM option string "
Djava.class.path=/sviluppo/java/pljava/org.postgresql.pljava/build"
20100601 13:55:03 CEST DEBUG: Added JVM option string "Dsqlj.defaultconnection=jdbc:default:connection"
20100601 13:55:03 CEST DEBUG: Added JVM option string "vfprintf"
20100601 13:55:03 CEST DEBUG: Added JVM option string "Xrs"
20100601 13:55:03 CEST DEBUG: Creating JavaVM
20100601 13:55:03 CEST DEBUG: JavaVM created
20100601 13:55:03 CEST DEBUG: Getting Backend class pljava.jar
150 di 182
Un primo esempio di funzione
CREATE FUNCTION getsysprop(VARCHAR)
RETURNS VARCHAR
AS 'java.lang.System.getProperty'
LANGUAGE java;
151 di 182
Scrivere funzioni PL/Java
Ogni metodo invocabile in PostgreSQL deve
essere un metodo statico (i parametri devono
corrispondere a quelli passati alla funzione SQL).
Ogni funzione Java deve essere invocata tramite
una funzione SQL.
Le classi devono essere contenute in un file jar
caricato e impostato nel classpath del database.
Il classpath viene
amministratori.
gestito
solo
dagli
utenti
ATTENZIONE: se vengono riportate eccezioni di sicurezza
significa che la classe è presente nel classpath del processo
postmaster e quindi viene caricata senza passare dal motore
database!
152 di 182
Un secondo esempio di funzione
153 di 182
Parametri e tipi di ritorno: un esempio
154 di 182
NULL vs null
Il tipo NULL del linguaggio SQL viene tradotto
nel tipo null di Java.
Però per SQL è lecito avere NULL anche dove
c'è uno scalare, mentre per Java no!
Di conseguenza le funzioni che lavorino con
scalari (in ingresso/uscita) e che debbano
gestire tipi NULL (SQL) devono usare le classi
wrapper.
155 di 182
Funzioni che restituiscono un SETOF
Pl/Java richiede che una funzione che ritorna un SETOF (lato
SQL) restituisca un Iterator (lato Java). Non verranno
accettati altri tipi di ritorno!
E' comunque possibile usare un qualunque tipo di
dato/struttura che implementi l'interfaccia Iterator.
156 di 182
Creazione di Trigger
Il codice Java dipende dalle librerie Pl/Java
Ogni funzione trigger non restituisce nulla (void) e accetta
come parametro un oggetto TriggerData con le
informazioni sull'invocazione del Trigger.
Tramite TriggerData è possibile selezionare il result set
new oppure old e su questi agire (old è in sola lettura).
157 di 182
Esempio di Trigger
Si vuole creare un trigger che modifichi una stringa di testo con le metainformazioni sul trigger stesso.
158 di 182
Esempio di Trigger
159 di 182
Esempio piu' complesso di Trigger
Si supponga di voler tenere traccia del numero globali di
invocazioni della funzione trigger, del numero di update di una riga
e di impedire le cancellazioni delle righe che sono state aggiornate
un numero pari di volte.
160 di 182
Codice della funzione Trigger
public class Trigger {
public static int globalCounter = 0;
public static void triggerJavaMethod( TriggerData triggerData ) throws SQLException{
// e' un trigger per update?
if( triggerData.isFiredByUpdate() ){
// prelevo il result set nuovo
ResultSet newRS = triggerData.getNew();
// prelevo il vecchio result set
ResultSet oldRS = triggerData.getOld();
// inserisco il contatore globale
newRS.updateInt("global_counter", ++globalCounter);
// incremento il contatore di update
newRS.updateInt("update_counter", oldRS.getInt("update_counter") + 1);
}
else if( triggerData.isFiredByDelete() ){
ResultSet oldRS = triggerData.getOld();
if( ( oldRS.getInt("update_counter") % 2 ) == 0 )
throw new TriggerException(triggerData, "Tupla non ..");
}
}
Non esiste ancora un metodo efficace per gestire l'abort di un trigger!
Lanciare una eccezione non funziona appieno: blocca la transazione
nel backend!
161 di 182
Esecuzione del Trigger
162 di 182
Maneggiare tipi complessi
I tipi complessi devono essere trattati tramite un ResultSet
aggiornabile.
Si rinuncia al paradigma OOP per passare ad un paradigma in stile
record-based.
E' comodo usare un ResultSetGenerator:
La funzione (lato SQL) richiama un metodo (lato Java) statico che
restituisce
un
oggetto
che
implementa
l'interfaccia
ResultSetProvider.
ResultSetProvider
contiene
due
metodi:
assignRowValues(..) che permette l'update di una cella
(riga/colonna) nel ResultSet e close() usato per rilasciare le
risorse.
ResultSetProvider.assignRowValues(..)
restituisce
false se non ci sono altre righe da processare, true se
ancora una riga deve essere inserita nel ResultSet.
163 di 182
Maneggiare tipi complessi: generare delle tuple
public class RowGenerator implements ResultSetProvider {
private static int NUM_ROWS = 10;
private static int NUM_COLS = 5;
public boolean assignRowValues(ResultSet rs, int rowNumber)
if( rowNumber <= NUM_ROWS ){
for( int j = 1; j <= NUM_COLS; j++ )
rs.updateString(j, "Riga " + rowNumber + " Colonna " + j);
return true;
}
else
return false;
}
public void close() throws SQLException {
System.out.println("Chiusura del row set provider");
}
public static ResultSetProvider generateRows(){
return new RowGenerator();
}
}
164 di 182
Maneggiare tipi complessi: invocazioni SQL
165 di 182
JDBC & Pl/Java =~ SQL MED
E' possibile chiamare JDBC da Pl/Java, in modo da poter
interrogare in modo riflessivo il database al quale si è connessi.
In questo modo si possono ottenere (e restituire) i dati
appartenenti ad altre tabelle/relazioni.
166 di 182
public class RowGenerator implements ResultSetHandle {
private String databaseName;
private String username;
private String password;
private String tableName;
public RowGenerator(String database, String username, String password, String table ){
this.databaseName = database;
this.username = username;
this.password = password;
this.tableName = table;
}
// funzione usata lato SQL
public static ResultSetHandle generateRows(String database, String username, String password, String table){
return new RowGenerator( database, username, password, table );
}
167 di 182
JDBC & Pl/Java = SQL MED
// funzione usata per ottenere le tuple
public ResultSet getResultSet() throws SQLException {
org.postgresql.Driver driver = new org.postgresql.Driver();
Connection connection = DriverManager.getConnection( this.databaseName, this.username, this.password );
return statement.executeQuery(" SELECT * FROM "+ this.tableName );
}
}
Se la funzione viene creata come linguaggio untrusted allora è possibile usare la
connessione verso ogni database, e quindi implementare un SQL MED completo.
ATTENZIONE: i driver devono trovarsi nel classpath!
168 di 182
Utilizzo dei SavePoint
public static void executeInsert(int counter) throws SQLException{
Connection connection = DriverManager.getConnection("jdbc:default:connection");
Savepoint save = null;
// effettuo 10 inserimenti
for( int i = 0; i < counter; i++ ){
statement.execute("INSERT INTO java_table(nome) VALUES('inserimento" + i + "')");
if( i >= (counter / 2) && save == null )
save = connection.setSavepoint();
}
// rollback connection.rollback( save );
}
169 di 182
SavePoint: risultato
170 di 182
Listener
private static Logger logger = Logger.getAnonymousLogger();
public static void executeInsert(int counter) throws SQLException{
Connection connection = DriverManager.getConnection("jdbc:default:connection");
Session session = SessionManager.current();
session.addSavepointListener( new SavepointListener() {
public void onStart(Session arg0, Savepoint arg1, Savepoint arg2)
logger.info("Savepoint START " + arg0 + " savepoints " + arg1 + " " + arg2);
}
public void onCommit(Session arg0, Savepoint arg1, Savepoint arg2)
logger.info("Savepoint COMMIT" + arg0 + " savepoints " + arg1 + " " + arg2);
}
public void onAbort(Session arg0, Savepoint arg1, Savepoint arg2)
logger.info("Savepoint ABORT " + arg0 + " savepoints " + arg1 + " " + arg2);
}
});
171 di 182
Listener
E' possibile agganciare dei listener per le
transazioni (TransactionListener) e per la
gestione dei SavePoint (sotto-transazioni)
(SavePointListener).
172 di 182
public class RowGenerator implements ResultSetHandle {
private String databaseName;
private String username;
private String password;
private String tableName;
public RowGenerator(String database, String username, String password, String table ){
this.databaseName = database;
this.username = username;
this.password = password;
this.tableName = table;
}
public static ResultSetHandle generateRows(String database, String username, String password, String table){
return new RowGenerator( database, username, password, table );
}
public ResultSet getResultSet() throws SQLException {
Connection connection = DriverManager.getConnection( this.databaseName, this.username, this.password );
return statement.executeQuery(" SELECT * FROM "+ this.tableName );
}
}
173 di 182
Singleton e PooledObjects
Pl/Java consente la gestione di oggetti in un pool,
ovvero un recipiente di oggetti che possono essere
riciclati per scopi futuri. In un certo senso questo
aiuta nel paradigma dei singleton.
Ogni oggetto che deve essere gestibile da un pool
deve implementare l'interfaccia PooledObject e
implementare i metodi per la attivazione e
disattivazione.
Il costruttore dell'oggetto deve accettare il pool di
appartenenza (ObjectPool) sul quale puo'
operare.
174 di 182
Esempio di PooledObject
public class Pooled implements PooledObject{
private long creationTimeMillis;
private ObjectPool myPool;
public Pooled( ObjectPool myPool ){
super();
this.creationTimeMillis = Calendar.getInstance().getTimeInMillis();
this.myPool = myPool;
}
public void activate() throws SQLException {
System.out.println("Oggetto <" + creationTimeMillis + "> attivato!");
}
public void passivate() throws SQLException {
System.out.println("Oggetto <" + creationTimeMillis + "> disattivato!");
}
175 di 182
public void remove() {
System.out.println("Oggetto <" + creationTimeMillis + "> rimosso!");
}
public static void createPooledObject() throws SQLException{
// ottengo la sessione corrente
Session session = SessionManager.current();
// ottengo il pool di oggetti
ObjectPool pool = session.getObjectPool( Pooled.class );
// ottengo una istanza dal pool
Pooled myPooled = (Pooled) pool.activateInstance();
// ci faccio qualcosa....
// poi lo reinserisco nel pool
pool.passivateInstance(myPooled);
}
}
176 di 182
Se si invoca ripetutamente la funzione di
generazione dell'oggetto si nota che è sempre
lo stesso oggetto ad essere usato.
Se l'oggetto non viene reinserito nel pool, allora
un nuovo viene creato e usato.
177 di 182
Multithreading
Problema: Java è un linguaggio che supporta il multithreading, ma il backend PostgreSQL è un singolo
processo senza supporto ai thread.
Il supporto al multithreading di Java deve essere
comunque garantito!
Se si pensa al backend come ad un ennesimo thread,
allora tutti i thread (Java e di backend) devono
sincronizzarsi in modo coerente: si utilizza un singolo lock!
Viene
definito
un
oggetto
particolare,
Backend.THREADLOCK sul quale tutti si sincronizzano.
il
178 di 182
Backend.THREADLOCK
179 di 182
Funzionamento del lock
L'idea è semplice: il lock funziona come un mutex.
Il processo backend detiene il lock dall'inizio.
Quando il processo chiama una funzione Java (ad
esempio perché scatta un trigger) rilascia il lock.
La funzione Java acquisisce il lock.
Quando la funzione Java termina il backend
riacquisisce il lock.
Così facendo il lock garantisce che ci sia sempre e
solo un flusso di esecuzione: o il backend è in
attesa della terminazione di Java oppure Java è in
attesa della terminazione di un flusso di backend.
180 di 182
Funzionamento del lock
Backend
Backend
Java
Java
SELECT example1();
risultati
<fine>
181 di 182
Utilizzo del lock
Tutti i metodi della classe Portal.java (e delle classi
che rappresentano oggetti del backend) utilizzano il lock
come prima istruzione al fine di ottenere il lock dal
backend. Ovviamente il lock va acquisito qualora si
debba procedere con un metodo nativo.
public int fetch(boolean forward, int count) throws SQLException { synchronized(Backend.THREADLOCK) { return _fetch(m_pointer, System.identityHashCode(
Thread.currentThread()), forward, count); }
182 di 182

PostgreSQL-Java

Transcript

Documenti analoghi

accesso via JDBC

impag. 2003 (parte 3 ) qb03

Trailer cinematografico: Luka (2013)

Software utilizzato

JDBC

Database Management Systems - Università degli Studi di Trento

La programmazione

BIOGRAFIA - Luca Olivieri