Tecnologie Web T Gestione delle Transazioni e Livelli di Isolamento

Transcript

1 Tecnologie Web T Gestione delle Transazioni e Livelli di Isolamento Home Page del corso: Versione elettronica: 4.03.Transazioni.pdf Versione elettronica: Transazioni-2p.pdf 1 Introduzione Caratteristica di base delle nostre applicazioni Web è quella di avere un elevato numero di utenti che accedono, anche in maniera concorrente, ai dati (base di dati) verso i quali si interfacciano Il sistema di gestione dei dati (DBMS) deve garantire affidabilità e prestazioni la base di dati deve essere sempre in uno stato consistente La gestione della concorrenza e della affidabilità nell'accesso ai dati è una delle proprietà fondamentali che ci offrono i moderni DBMS Un concetto cardine è quello di transazione 2 1

2 Transazioni Informalmente, una transazione è una sequenza di operazioni che può concludersi con un successo o un insuccesso in caso di successo: il risultato delle operazioni deve essere permanente in caso di insuccesso: si deve tornare allo stato precedente all'inizio della transazione 3 Definizione di transazione Transazione parte di programma caratterizzata da un inizio (begintransaction, start transaction in SQL), una fine (end-transaction, non esplicitata in SQL) e al cui interno deve essere eseguito una e una sola volta uno dei seguenti comandi: commit work per terminare correttamente rollback work per abortire la transazione Un sistema transazionale (OLTP) è in grado di definire ed eseguire transazioni per conto di un certo numero di applicazioni concorrenti 4 2

3 Applicazioni e transazioni L'esecuzione di un programma può essere visto come una sequenza di transazioni (eventualmente intervallate da operazioni non relative ai dati) begin T1 AZIONI TRANSAZIONE T1 PROGRAMMA APPLICATIVO end T1 begin T2 AZIONI TRANSAZIONE T2 end T2 5 Una transazione SQL Esempio: trasferimento di 10 unità dal conto al conto start transaction; update ContoCorrente set Saldo = Saldo + 10 where NumConto = 12202; update ContoCorrente set Saldo = Saldo - 10 where NumConto = 42177; commit work; 6 3

4 Una transazione con varie decisioni Esempio: trasferimento di 10 unità dal conto al conto con il controllo che il saldo del cc da cui si preleva sia positivo start transaction; update ContoCorrente set Saldo = Saldo + 10 where NumConto = 12202; update ContoCorrente set Saldo = Saldo 10 where NumConto = 42177; select Saldo as A from ContoCorrente where NumConto = 42177; if (A>=0) then commit work; else rollback work; 7 Il concetto di transazione Una definizione più precisa di transazione: unità di elaborazione che gode delle proprietà "ACIDE" (ACID): Atomicità Consistenza Isolamento Durabilità (persistenza) 8 4

5 ACID: Atomicità Una transazione è una unità atomica (tutto o niente) di elaborazione È fondamentale per garantire l'integrità dei dati Se qualcosa va storto il sistema deve essere in grado di annullare tutti i cambiamenti fatti a partire dall'inizio della transazione La base di dati non può essere lasciata in uno stato intermedio un guasto o un errore prima del commit debbono causare l'annullamento (UNDO) delle operazioni svolte un guasto o errore dopo il commit non deve avere conseguenze Esito Commit = caso "normale" e più frequente Abort (o rollback) richiesto dall'applicazione = suicidio richiesto dal sistema (violazione dei vincoli, concorrenza, incertezza in caso di fallimento) = omicidio 9 ACID: Consistenza La transazione rispetta i vincoli di integrità Conseguenza: se lo stato iniziale è corretto anche lo stato finale è corretto 10 5

6 ACID: Isolamento La transazione non risente degli effetti delle altre transazioni concorrenti l'esecuzione concorrente di una collezione di transazioni deve produrre un risultato che si potrebbe ottenere con una esecuzione sequenziale Conseguenza: una transazione non espone i suoi stati intermedi 11 ACID: Durabilità (Persistenza) Gli effetti di una transazione andata in commit non vanno perduti ("durano per sempre"), anche in presenza di guasti Commit significa impegno 12 6

7 Controllo di concorrenza Se la proprietà di isolamento non è completamente soddisfatta, due (o più) transazioni effettuate su un database consistente possono portare il database in uno stato inconsistente Due azioni sullo stesso oggetto si dicono essere in confitto se almeno una delle due è una operazione di scrittura Date due transazioni T1 e T2 in conflitto, si possono verificare tre tipologie di situazioni anomale conflitto Write-Read (W-R): T2 legge un dato precedentemente scritto da T1 conflitto Read-Write (R-W): T2 scrive un dato precedentemente letto da T1 conflitto Write-Write (W-W): T2 scrive un dato precedentemente scritto da T1 13 Conflitti WR: Reading uncommitted data Si può verificare una anomalia se una transazione T2 legge un dato che è stato modificato da una transazione T1 non ancora conclusa (quindi uncommitted) In particolare questa situazione può generare letture sporche 14 7

8 Lettura sporca t 1 traferisce 100 da A a B t 2 incrementa sia A che B del 6% N.B. Assumiamo sempre un begin of transaction (BOT ) come prima operazione di ogni transazione 15 Lettura sporca supponiamo che sia A che B all'inizio valgano 1000: con una esecuzione seriale t 1 t 2 t 1 t 2 tempo r 1 (A) A = A w 1 (A) r 1 (B) B = B w 1 (B) commit r 2 (A) A = A * 1.06 w 2 (A) r 2 (B) B = B * 1.06 w 2 (B) commit A = 900*1.06 = 954 B = 1100*1.06 = 1166 A+B=

9 Lettura sporca supponiamo che sia A che B all'inizio valgano 1000: con una esecuzione seriale t 2 t 1 t 1 t 2 tempo r 1 (A) A = A w 1 (A) r 1 (B) B = B w 1 (B) commit r 2 (A) A = A * 1.06 w 2 (A) r 2 (B) B = B * 1.06 w 2 (B) commit A = 960 B = 1160 A+B = Lettura sporca supponiamo che sia A che B all'inizio valgano 1000: con esecuzione concorrente di t 2 t 1 t 1 t 2 tempo r 1 (A) A = A w 1 (A) r 1 (B) B = B w 1 (B) commit r 2 (A) A = A * 1.06 w 2 (A) r 2 (B) B = B * 1.06 w 2 (B) commit t 2 ha letto uno stato intermedio ("sporco") A = 954 B = 1160 NB: alla fine qualcuno ci ha perso... e il totale cambia: chi ha guadagnato? 18 9

10 Conflitti RW: Unrepeatable read Si possono verificare diverse anomalie se una transazione T2 cambia il valore di un dato che è stato letto da una transazione T1 mentre T1 è ancora in esecuzione In particolare, questa situazione può generare: perdita di aggiornamento, lettura inconsistente (unrepeatable read) 19 Letture inconsistenti t 1 legge due volte x : t 1 t 2 tempo r 1 (x) r 1 (x) commit r 2 (x) x = x + 1 w 2 (x) commit t 1 legge due valori diversi per x! 20 10

11 Perdita di aggiornamento Due transazioni identiche: t 1 : r(x), x = x + 1, w(x) t 2 : r(x), x = x + 1, w(x) Inizialmente x=2; dopo una esecuzione seriale x=4 Una esecuzione concorrente: tempo t 1 t 2 r 1 (x) x = x + 1 w 1 (x) commit r 2 (x) x = x + 1 w 2 (x) commit Un aggiornamento viene perso: x = 3 21 Conflitti WW: Overwriting uncommitted data Si possono verificare anomalie se una transazione T2 sovrascrive il valore di un dato che è già stato modificato da una transazione T1, mentre T1 è ancora in esecuzione questa situazione può generare effetti fantasma 22 11

12 Effetti fantasma vincolo: x+y+z=1000 tempo t 1 t 2 sum = 0 read(x) sum = sum + x read(y) sum = sum + y read(z) sum = sum + z commit read(y) y = y write(y) read(z) z = z write(z) commit T1 calcola in maniera errata la somma di x, y, z (supponiamo T2 stia spostando soldi dal conto y al conto z: il totale di cassa non cambia per T1 invece si!) 23 Gestione di transazioni mediante lock I DBMS per evitare anomalie nelle transazione concorrenti usano diverse tecniche Una delle più comuni è basata su lock Il lock è un meccanismo che blocca l'accesso ai dati ai quali una transazione accede ad altre transazioni lock a livello di riga, tabella, database lock in operazioni di scrittura/lettura Quando una risorsa è bloccata, le transazioni che ne richiedono l'accesso vengono messe in coda quindi devono aspettare (che il lock sia rimosso) In sostanza, questo è un meccanismo efficace, ma influisce sulle prestazioni 24 12

13 Livelli di isolamento Idealmente vorremmo avere sempre garantita la proprietà di isolamento delle transazioni Ma questa proprietà ha dei costi che possono limitare le prestazioni del sistema I DBMS offrono diversi livelli di isolamento: maggiori restrizioni, minori prestazioni Il programmatore deve conoscere i livelli di isolamento e scegliere quello sufficiente ai propri obiettivi 25 Livelli di isolamento SQL SERIALIZABLE assicura che la transazione T legge solo cambiamenti fatti da transazioni concluse nessun valore letto o scritto da T verrà cambiato da altre transazione finché T non è conclusa se T legge un insieme di valori acceduti secondo qualche condizione di ricerca, l'insieme non viene modificato da altre transazione finché T non è conclusa REPEATABLE READ assicura che la transazione T legge solo cambiamenti fatti da transazioni concluse nessun valore letto o scritto da T verrà cambiato da altre transazione finché T non è conclusa READ COMMITTED assicura che la transazione T legge solo cambiamenti fatti da transazioni concluse T non vede nessun cambiamento eventualmente effettuato da transazioni concorrenti non concluse tra i valori letti all'inizio di T READ UNCOMMITTED a questo livello di isolamento una transazione T può leggere modifiche fatte ad un oggetto da un transazione in esecuzione; ovviamente l'oggetto può essere cambiato mentre T è in esecuzione. Quindi T è soggetta a effetti fantasma 26 13

14 Livelli di isolamento SQL Il livello di isolamento può essere scelto per ogni transazione read uncommitted permette letture sporche, letture inconsistenti, aggiornamenti fantasma e inserimenti fantasma read committed evita letture sporche ma permette letture inconsistenti, aggiornamenti fantasma e inserimenti fantasma repeatable read evita tutte le anomalie esclusi gli inserimenti fantasma serializable evita tutte le anomalie Nota: la perdita di aggiornamento è sempre evitata Inoltre le transazioni possono essere definite read-only 27 Livelli di isolamento e anomalie livello di isolamento lettura sporca lettura inconsistente effetto fantasma READ UNCOMMITTED READ COMMITTED REPEATABLE READ può verificarsi può verificarsi può verificarsi NO può verificarsi può verificarsi NO NO può verificarsi SERIALIZABLE NO NO NO 28 14

15 Transazioni in SQL START TRANSACTION SET TRANSACTION ISOLATION LEVEL livello istruzioni SQL COMMIT 29 Transazioni in JDBC Scelta della modalità delle transazioni: un metodo definito nell'interfaccia Connection: setautocommit(boolean autocommit) connection.setautocommit(true) (default) "autocommit ": ogni operazione è una transazione connection.setautocommit(false) gestione delle transazioni da programma connection.commit() connection.rollback() N.B. non c'èstart transaction 30 15

16 JDBC e livelli di isolamento Il metodo settransactionisolation() permette di modificare il livello di isolamento delle transazioni Riceve un parametro intero che può assumere uno dei valori costanti definiti nella interfaccia Connection TRANSACTION_NONE: le transazioni non vengono supportate. Passare questo parametro a settransactionisolation() è equivalente ad una chiamata al metodo setautocommit(true) TRANSACTION_READ_UNCOMMITTED: nessun livello di isolamento è garantito, quindi possono presentarsi tutte le anomalie 31 JDBC e livelli di isolamento TRANSACTION_READ_COMMITTED: vengono prevenute solo le letture sporche. Le altre anomalie possono ancora presentarsi TRANSACTION_REPEATABLE_READ: possono presentarsi solo inserimenti fantasma TRANSACTION_SERIALIZABLE: è il massimo livello di isolamento. Nessuna anomalia può presentarsi 32 16

17 Esempio transazioni con JDBC public void evadiordine (int codprodotto, String idordine, int qnt, Connection con) throws PersistenceException { try { try { con.setautocommit(false); con.setautocommit(false); con.settransactionlevel(connection.transaction_repeatable_read); PreparedStatement PreparedStatement updateprod updateprod = = con.preparestatement("update prodotti SET quantita=(quantita -?) WHERE codiceprodotto =? "); updateprod.setint(1, updateprod.setint(1, codprodotto); codprodotto); updateprod.setint(2, updateprod.setint(2, qnt); qnt); PreparedStatement PreparedStatement updateord = updateord = con.preparestatement("update con.preparestatement("update ordini SET ordini stato = SET 'evaso' stato where = 'evaso' idordine=?"); where idordine=?"); updateord.setint(1, updateord.setint(1, idordine); idordine); int nprod = int prepareprod.executeupdate(); nprod = prepareprod.executeupdate(); int nord = int prepareord.executeupdate(); nord = prepareord.executeupdate(); if (nprod+nord if (nprod+nord!= 2)!= 2) con.rollback(); con.rollback(); else else con.commit(); con.commit(); } catch (SQLException ex) { try } catch { (SQLException ex) { con.rollback(); try { con.rollback(); throw new PersistenceException("Transaction failed: " + ex.getmessage()); throw new PersistenceException("Transaction failed: " + ex.getmessage()); } catch (SQLException sqx) { } catch (SQLException sqx) { throw new PersistenceException("Rollback failed: sqx.getmessage()); throw new PersistenceException("Rollback failed: " + sqx.getmessage()); } } } 33 JDBC e livelli di isolamento Attenzione: non tutti i DBMS supportano le transazioni e non tutti quelli che le supportano permettono l'impostazioni di tutti i livelli di isolamento previsti da JDBC È compito del programmatore che usa l'api JDBC verificare le effettive capacità del DBMS in uso A tal fine l'interfaccia Connection mette a disposizione il metodo getmetadata(), che restituisce un oggetto DatabaseMetaData 34 17

18 JDBC e livelli di isolamento L'interfaccia DatabaseMetaData offre metodi per reperire informazioni sul DBMS In particolare, per verificare il supporto alle transazioni, abbiamo i metodi: supportstransactions(): restituisce true se le transazioni sono supportate dal database, false se non lo sono. In questo ultimo caso, il metodo commit() non esegue alcuna operazione e il livello di isolamento è sempre TRANSACTION_NONE supportstransactionisolationlevel(int): permette di sapere se il DBMS supporta il livello di isolamento passato come parametro (secondo le costanti definite dall'interfaccia Connection nella slide precedente) 35 JDBC e livelli di isolamento import java.sql.*; public class TransactionCapabilities { public static void main(string[] args) throws SQLException { try { Class.forName("COM.ibm.db2.jdbc.app.DB2Driver"); } catch(classnotfoundexception e) { System.err.println("Driver non trovato"); } String url = "jdbc:db2:tw_stud"; Connection con = null; try { con = DriverManager.getConnection(url, ******", ******"); }catch(sqlexception e){ System.err.println("Connessione non restituita"); } try { DatabaseMetaData dbmetadata = con.getmetadata(); if (dbmetadata.supportstransactions()) System.out.println("tranzazioni supportate"); if (dbmetadata.supportstransactionisolationlevel(connection.transaction_read_uncommitted)) System.out.println("TRANSACTION_READ_UNCOMMITTED"); if (dbmetadata.supportstransactionisolationlevel(connection.transaction_read_committed)) System.out.println("TRANSACTION_READ_COMMITTED"); if (dbmetadata.supportstransactionisolationlevel(connection.transaction_repeatable_read)) System.out.println("TRANSACTION_REPEATABLE_READ"); if (dbmetadata.supportstransactionisolationlevel(connection.transaction_serializable)) System.out.println("TRANSACTION_SERIALIZABLE"); } catch(sqlexception e){ System.err.println("Errori lettura metadati"); } finally { con.close(); } } } 36 18

19 Limiti di JDBC JDBC rappresenta una buona soluzione per la gestione di transazioni che manipolano un unico DB, ovvero che coinvolgono una unica Connection! In sistemi che manipolano dati appartenenti a diversi DB, ogni unità di lavoro richiede l accesso a più di una risorsa in questi casi non è possibile garantire la propietà ACID di atomicità con JDBC! Occorre un transaction manager in grado di gestire diverse sorgenti dati (DB) in un unico sistema transazionale 37 Java Transaction API (JTA) Java Transaction API (JTA) fornisce un servizio per la gestione di transazioni distribuite per la piattaforma J2EE Una transazione distribuita coinvolge un transaction manger e uno o più resource manger (ovvero qualunque tipo di datastore persistente) Il transaction manger è responsabile del coordinamento di tutti i partecipanti alla transazione 38 19

20 JTA JTA permette l interazione con lo sviluppatore mediante l interfaccia javax.transaction.usertransaction e i metodi begin(), commit() e rollback() Starting a transaction with JTA: Example import javax.transaction.*; import javax.naming.*; //... UserTransaction utx = (UserTransaction) new InitialContext().lookup("java:comp/UserTransaction"); utx.begin(); //... DataSource ds = obtainxadatasource(); Connection conn = ds.getconnection(); pstmt = conn.preparestatement("update MOVIES..."); pstmt.setstring(1, "Spinal Tap"); pstmt.executeupdate(); //... utx.commit(); // Transazioni e Hibernate Come visto nelle precedenti lezioni, Hibernate astrae dalle API JDBC/JTA sottostanti livello di applicazione può essere trasparente a questi dettagli Hibernate espone l interfaccia org.hibernate.transaction che permette di lavorare on top a JDBC e JTA Rappresenta la demarcazione unificata delle transazioni Compatibile sia a JDBC che a JTA Il maggior beneficio di Hibernate rispetto a JDBC e JTA è di permettere stretta integrazione con il contesto di persistenza Es. flush automatico di Session al commit 40 20

21 Transazioni e Hibernate: Esempio import java.util.*; import org.hibernate.*; import persistence.hibernateutil; //... //First unit of work Session session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = session.begintransaction(); User user = new User("pippo"); String userid = (String) session.save(user); tx.commit(); session.close(); // Hibernate Come già sappiamo, l interfaccia principale di Hibernate è Session All'apertura di un nuovo oggetto della classe Session metodo opensession()della classe SessionFactory viene creata una nuova connessione JDBC con la base di dati di default, Hibernate imposta l'autocommit a false ; dunque comincia a tutti gli effetti una transazione JDBC 42 21

22 Hibernate Una Session Hibernate si dice essere pigra ; questo è un punto a favore di Hibernate La Session non consuma alcuna risorsa fino a che le stesse non sono strettamente necessarie Solo all inizio di una transazione viene resa disponibile una Connection dal pool di connessioni La chiamata begintransaction() si traduce in setautocommit(false) nella Connection JDBC corrispondente 43 Hibernate Il blocco di statement SQL di una transazione sono eseguiti seguendo la regola il più tardi possibile (write-behind ), ovvero al flushing del contesto di persistenza della Session Ciò accade di default al commit() di Transaction Dopo il commit (o il roll-back) della transazione la connessione è rilasciata e unbound dalla Session L inizio di una nuova transazione con la stessa Session necessita di una nuova connessione dal pool di connessioni disponibili 44 22

23 Locking ottimistico di sessione In caso di accesso concorrente, affinché non occorrano anomalie di tipo lost-update, Hibernate prevede la possibilità di abilitare un meccanismo di locking ottimistico tale che nel momento in cui viene invocato il flushing, verifica se la porzione della base di dati che sarà modificata non sia cambiata se è cambiata lancia una eccezione StaleObjectStateException Per abilitare il locking ottimistico, nell'elemento class del file di mapping relativo alla classe su cui verte la modifica, è necessario definire l'attributo optimisticlock pari a all 45 Long-lived transactions Tra il momento in cui si leggono i dati dal DB ed il momento in cui eventuali modiche si rendono persistenti può trascorrere molto tempo Hibernate applica il pattern session-per-conversation: è necessario disabilitare il flushing automatico chiamando il metodo setflushmode(flushmode.manual) quando la sessione è aperta l'isolamento è garantito in quanto, abilitando il locking ottimistico, le modiche fatte in transazioni concorrenti sono riconosciute l'atomicità è garantita dal fatto che il flushing viene eseguito solo al termine della transazione, e se la sessione viene chiusa senza fare il flushing, la transazione viene abortita 46 23

24 Controllo ottimistico di concorrenza Per la gestione efficiente di accessi concorrenti Hibernate sfrutta la tecnica Optimistic Concurrency Control (OCC) OCC si basa sull assunzione che la maggior parte delle transazioni verso DB non sono in conflitto con altre transazioni; questo permette di essere piuttosto permissivi nel rilasciare la possibilità di esecuzione Se i conflitti sono rari, post-validazioni possono essere svolte efficientemente => alto throughput OCC sfrutta versioning dei dati per ottenere elevati gradi di concorrenza e alta scalabilità Version checking sfrutta numeri di versione o timestamp per fare la detection di aggiornamenti che possono determinare conflitti 47 Riferimenti JDBC API: index.html Hibernate API: 3.5/api/ Atzeni, Ceri, Fraternali, Paraboschi, Torlone Basi di dati Architetture e linee di evoluzione, McGraw-Hill Italia, 2009 Christian Bauer and Gavin King. Java Persistence with Hibernate, Manning 48 24