Deadlock, locking e MVCC

I livelli di isolamento sono la promessa; locking e MVCC sono i meccanismi che la rendono possibile. Durante i colloqui si fanno domande su questi aspetti per verificare se comprende cosa accade internamente quando le transazioni entrano in conflitto.

Esistono due strategie generali:

• Pessimistica (locking): blocca gli accessi in conflitto finché un lock non viene rilasciato.
• Ottimistica / MVCC: consente a tutti di leggere uno snapshot coerente e rileva i conflitti al momento del commit.

Questa lezione tratta i lock, i deadlock e MVCC, oltre ai compromessi tra queste strategie.

Il locking classico usa due modalità principali:

• Lock condiviso (S) per le letture. Più transazioni possono mantenere contemporaneamente un lock condiviso sulla stessa riga.
• Lock esclusivo (X) per le scritture. Una sola transazione può mantenerlo e il lock blocca tutti gli altri lock su quella riga.

La regola è: S è compatibile con S, mentre X non è compatibile con nulla. Chi scrive deve attendere tutti i lettori e i lettori devono attendere chi scrive.

È possibile richiedere un lock di scrittura sulle righe che si stanno soltanto leggendo, per impedire ad altri di modificarle prima che si agisca su di esse. Questo è il metodo standard per evitare gli aggiornamenti persi in un ciclo di lettura-modifica-scrittura.

SELECT ... FOR UPDATE acquisisce lock esclusivi sulle righe; le righe rimangono bloccate fino al COMMIT o al ROLLBACK.

Un deadlock si verifica quando due o più transazioni mantengono ciascuna un lock di cui l'altra ha bisogno, formando un ciclo dal quale nessuna può uscire.

Il caso da manuale è il seguente: T1 blocca la riga A e poi richiede la riga B; T2 blocca la riga B e poi richiede la riga A. Ciascuna attende indefinitamente l'altra.

I database rilevano questa situazione con un grafo di attesa. Quando viene individuato un ciclo, il motore sceglie una vittima e la interrompe, restituendo un errore di deadlock affinché le altre transazioni possano continuare.

Osservi come si incrociano gli ordini dei lock. T1 acquisisce la riga 1 e poi richiede la riga 2; T2 acquisisce la riga 2 e poi richiede la riga 1. Nessuna delle due rilascia il proprio lock, quindi il motore interrompe una delle due transazioni.

La transazione interrotta riceve un errore come deadlock detected e deve essere ritentata. Quella superstite esegue il commit normalmente.

Non è possibile eliminare completamente i deadlock, ma è possibile renderli rari. Le risposte standard durante un colloquio sono:

• Ordine coerente dei lock: acquisisca sempre le righe nello stesso ordine (per esempio, secondo id crescente). In questo modo si interrompe il ciclo.
• Mantenga brevi le transazioni: mantenga i lock per il minor tempo possibile.
• Riduca il livello di isolamento quando è sicuro farlo: meno lock significano meno conflitti.
• Aggiunga la logica di retry: le transazioni vittime di un deadlock dovrebbero essere ritentate automaticamente.

L'ordine coerente è la soluzione più efficace in assoluto ed è quella che gli intervistatori vogliono sentire per prima.

I lock possono essere acquisiti a diversi livelli, con un compromesso tra concorrenza e overhead:

• I lock a livello di riga consentono un'elevata concorrenza, ma hanno un costo di gestione maggiore.
• I lock a livello di pagina o di tabella sono più economici da tracciare, ma bloccano un numero maggiore di transazioni.

Alcuni motori passano dai lock a livello di riga ai lock a livello di tabella quando una transazione coinvolge troppe righe (escalation dei lock). Sapere questo spiega perché un grande UPDATE in blocco può improvvisamente bloccare tutti.

MVCC (Multi-Version Concurrency Control) è il meccanismo con cui Postgres, Oracle e InnoDB evitano la maggior parte dei lock di lettura. Invece di bloccare le righe, il database conserva più versioni di ciascuna riga.

Il vantaggio principale, nonché una frase molto apprezzata durante i colloqui, è il seguente: i lettori non bloccano gli scrittori e gli scrittori non bloccano i lettori.

Ogni transazione vede uno snapshot coerente relativo a un determinato istante, mentre gli scrittori creano nuove versioni delle righe invece di sovrascriverle direttamente.

Quando una riga viene aggiornata, MVCC scrive una nuova versione e conserva quella precedente. Ogni versione contiene metadati relativi all'ID della transazione (in Postgres, xmin e xmax) che indicano quando è diventata visibile e quando è stata sostituita.

Lo snapshot di una transazione determina quale versione può vedere. Le vecchie versioni che nessuna transazione può più vedere diventano tuple obsolete e vengono recuperate in seguito da un processo di pulizia. In Postgres questo processo è VACUUM; non eseguirlo provoca il table bloat, una domanda frequente di approfondimento.

Riassumiamo il confronto in modo chiaro:

• Locking puro: correttezza semplice da garantire, ma lettori e scrittori si bloccano a vicenda, riducendo la concorrenza.
• MVCC: ottima concorrenza in lettura, nessun lock di lettura, ma il vantaggio ha il costo di dover conservare e ripulire le versioni (VACUUM, bloat); inoltre servono comunque lock per i conflitti tra scritture.

Anche i motori MVCC usano lock durante le scritture: due transazioni che aggiornano la stessa riga devono essere serializzate. MVCC elimina la contesa tra lettori e scrittori, non quella tra scrittori.

Oltre all'MVCC a livello di motore, le applicazioni spesso aggiungono il locking ottimistico per le operazioni di lettura-modifica-scrittura che si estendono su sessioni utente lunghe. Si aggiunge una colonna version, la si legge e, al momento dell'aggiornamento, si richiede che la versione corrisponda, incrementandola.

Se un'altra transazione ha aggiornato prima la riga, la versione non corrisponde più, nessuna riga viene modificata e il codice sa di dover ricaricare i dati e ritentare. Non viene mantenuto alcun lock mentre l'utente riflette, quindi la concorrenza rimane elevata. Gli intervistatori apprezzano questa soluzione per la domanda: "come gestirebbe due utenti che modificano lo stesso record?".

Verifichi di aver compreso il concetto fondamentale di MVCC.

Ora è in grado di spiegare i meccanismi alla base dell'isolamento:

• I lock condivisi/esclusivi coordinano gli accessi; SELECT FOR UPDATE acquisisce lock di scrittura espliciti.
• I deadlock sono cicli di lock; il motore interrompe una transazione vittima e un ordine coerente dei lock ne previene la maggior parte.
• MVCC conserva le versioni delle righe, in modo che lettori e scrittori non si blocchino a vicenda, al costo della pulizia (VACUUM, bloat).

Associando questi meccanismi ai livelli di isolamento e alle anomalie delle lezioni precedenti, può affrontare un colloquio sulla concorrenza dall'inizio alla fine.