Basi di dati II - gli approcci MVCC

2PL-MVCC

Serve a fare in modo, così come negli altri approcci MVCC, che le letture siano sempre soddisfatte. L’idea è questa: per ogni oggetto X della base di dati vengono tenute 2 copie:

• X1: l’ultima copia modificata dopo un successful commit.
• X2: una copia in fase di modifica.

Viene inoltre aggiunto un terzo tipo di lock, il certify lock. Tutte le transazioni che vogliono solo leggere accedono in concorrenza agli oggetti X1, invece una transazione T che vuole scrivere avrà una copia degli oggetti interessati, X2, su cui potrà apportare le sue modifiche anche se ci sono transazioni che stanno leggendo proprio quei dati (la scrittura invece è sempre esclusiva).

Quando T è pronta ad effettuare il commit deve ottenere un certify lock su ogni oggetto X che ha modificato (quindi su cui detiene un write lock), siccome il certify lock è esclusivo rispetto a tutti gli altri lock sarà necessario che ogni transazione bloccata in

lettura su X1 rilasci il read lock prima che T possa effettuare il commit. Dopo il commit X1 verrà aggiornato alla versione modificata.

Approccio ottimistico

Nei sistemi in cui vi sono molte letture e relativamente poche scritture, approcci incentrati sul lock come quelli visti aggiungono un bel po' di overhead, che nella maggioranza dei casi potrebbe essere evitato.

Gli approcci ottimistici, come suggerisce il nome, partono dal presupposto che "andrà tutto bene" e quindi non applicano nessun controllo di concorrenza, salvo verificare alla fine se la modifica può essere accettata: in questo modo le transazioni sono servite alla massima velocità possibile.

Funziona così: si prevedono 3 fasi:

• Reading phase: lettura degli oggetti X ed eventuale modifica, effettuata però su copie locali a ciascuna transazione.
• Validation phase: in questa fase ogni transazione sottomette le modifiche fatte e queste devono essere validate.
• effettiva

Scrittura della modifica oppure all'abort della Write phase: si procede alla transazione se non si è passata la fase precedente.

A supporto del metodo a ogni transazione è associato un timestamp, inoltre per ogni fase vengono mantenuti i tempi di inizio e fine, nonché una lista degli oggetti letti (read set) e modificati (write set).

La fase di validazione si divide a sua volta in 3 fasi, dalla meno complessa alla più onerosa, e basta che una qualsiasi di queste sia soddisfatta per essere sicuri che la transazione non interferirà con le altre (quindi una transazione andrà in abort solo se falliscono tutte e tre).

Questo vuol dire che nel caso migliore basterà verificare solo la più semplice (e rapida!) per far passare una transazione. Vediamo ora nel dettaglio le 3 fasi: