PostgreSQL: Transazioni e locking
0 likes1,617 views
Il documento tratta le transazioni nei database, definendo la loro natura atomica, i livelli di isolamento e gli effetti della concorrenza sulle stesse. Viene discusso l'ACID (Atomicità, Coerenza, Isolamento e Durabilità) e i vari livelli di isolamento per prevenire problemi quali read dirty e phantom read. Infine, confronta il Multi-Version Concurrency Control (MVCC) con i tradizionali sistemi di locking, evidenziando le differenze nel trattamento delle operazioni di lettura e scrittura.
PostgreSQL: Transazioni e locking
- 1. Transazioni e concorrenza Cenni su Transazioni e concorrenza 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 1
- 2. Transazioni e concorrenza Definizione di transazione Effetti della concorrenza sulle transazioni Livelli di isolamento delle transazioni MVCC – Multi version concurrency control overview Differenze tra MVCC e locking Row level Locking 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 2
- 3. Cos'è una transazione E' un insieme di istruzioni che deve essere eseguita in maniera atomica → o tutto o niente Una transazione deve essere ACID Atomicity : atomicità, la transazione è indivisibile nella sua esecuzione e la sua esecuzione deve essere o totale o nulla, non sono ammesse esecuzioni intermedie; Consistency : coerenza, quando inizia una transazione il database si trova in uno stato coerente e quando la transazione termina il database deve essere in uno stato coerente, ovvero non deve violare eventuali vincoli di integrità, quindi non devono verificarsi contraddizioni (inconsistency) tra i dati archiviati nel DB Isolation, isolamento, ogni transazione deve essere eseguita in modo isolato e indipendente dalle altre transazioni, l'eventuale fallimento di una transazione non deve interferire con le altre transazioni in esecuzione Durability: persistenza, dopo un commit work, i cambiamenti apportati non dovranno essere più persi. 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 3
- 4. I livelli di isolamento Sono richiesti quattro livelli di isolamento delle transazioni per prevenire questi tre comportamenti indesiderabili Dirty read: una transazione legge i dati provenienti da una transazione simultanea uncomitted Non repeatable read: una transazione rilegge i dati che ha precendentemente letto e trova che i dati sono stati modificati da un'altra transazione che ha eseguito il commit dal momento della lettura iniziale phantom read: una transazione riesegue una query che restituisce un insieme di righe che soddisfano la condizione di ricerca e trova che l'insieme delle righe che soddisfano questa condizione è cambiato a causa di un'altra transazione che ha eseguito un commit di recente 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 4
- 5. I livelli di isolamento Isolation level Dirty Read Non repeatable read Phantom Read Read Uncommitted Possible Possible Possible Read Committed Not Possible Possible Possible Repeatable Read Not Possible Not Possible Possible Serializable Not Possible Not Possible Not Possible 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 5
- 6. I livelli di isolamento PostgreSQL possiede solo 2 livelli di isolamento : Read comitted, Serializable Read commited: E' il livello di isolamento di default Postgresql vede i dati che hanno avuto un commit prima che la transazione partisse. La query però può vedere gli effetti di aggiornamenti avvenuti all'interno della stessa transazioni che non possono essere visti da query al di fuori della transazione. Le transazioni non restano in attesa Serializable: le transazioni avvengono una di seguito all'altra, come se fossero in sequenza 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 6
- 7. I livelli di isolamento Dove si cambiano i livelli di isolamento? File postgresql.conf 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 7
- 8. Locking un esempio Begin work; lock table testtb; Transazione 1 ......... Select * from testtb; Transazione 2 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 8
- 9. Locking un esempio Istante Istante Tempo Tempo Transazione Transazione T1 T2 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 9
- 10. Locking un esempio Output Transazione 2 In attesa della fine del lock 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 10
- 11. Locking un esempio Commit work; Transazione 1 Dati dalla Transazione T2 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 11
- 12. Locking un esempio Facciamo un esempio Pratico? 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 12
- 13. Differenze MVCC Locking Nel modello MVCC i lock messi dal sistema durante le operazioni di scrittura non bloccano le operazioni di lettura e viceversa come avviene invece nei meccanismi di lock tradizionale Esistono dei sistemi di locking più raffinato? Si : ad esempio select ... for update o select ... for share che metteno un lock sulla singola riga che viene modificata, ed esegue un locking a livello di ROW 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 13
- 14. Punto della situazione Abbiamo parlato di Definizione di transazione Effetti della concorrenza sulle transazioni Livelli di isolamento delle transazioni MVCC – Multi version concurrency control overview Differenze tra MVCC e locking Row level Locking 27/11/08 /home/scotty/enrico/corsoweb/finale/Architettura/arch3.odp page 14