Race Conditions

Capire come funziona un database in isolamento su un singolo terminale è semplice, ma in un reale scenario web, ci saranno centinaia di processi "Node/PHP/Go" concorrenti che inviano richieste. Qui nascono le famose Race Conditions.

Il problema del "Lost Update"

Il Lost Update capita quando due thread leggono la stessa vecchia riga, ci fanno un calcolo matematico nel server JavaScript e poi rimandano indietro l'UPDATE per salvare il risultato.

Scenario:

• Il prodotto #5 ha 10 unità.
• L'utente A lo compra (Server A legge "10", calcola matematicamente "9").
• Nello stesso millisecondo l'utente B ne compra un altro prima che l'acquisto di A finisca la fase di COMMIT.
• Il Server B legge anche lui "10", calcola "9".
• Il Server A manda UPDATE: setta quantità = 9.
• Il Server B manda UPDATE: setta quantità = 9.
• Entrambi pensano di aver diminuito il numero con successo. Ma dovevano essere 8 unità finali! Un acquisto fantasma è stato perso.

Soluzione senza transazioni pesanti (Atomic Updates)

Invece di leggere e fare la matematica fuori, falli fare al DB durante l'update stessso che è sempre sincronizzato.

-- Sbagliato
UPDATE products SET stock = 9 WHERE id = 5;

-- Corretto e thread-safe nativo
UPDATE products SET stock = stock - 1 WHERE id = 5;

Anomalie più estreme (Dirty Reads & Phantoms)

• Dirty Read: Leggi dati temporanei altrui che non sono stati ancora confermati da un COMMIT (e potrebbero andare in ROLLBACK di colpo invalidandoti).
• Phantom Reads: Fai uno scan di tutte le righe, nel frattempo un secondo thread inserisce un record nuovo, poi fai un altro scan durante la medesima transazione e ti ritrovi magicamente con il nuovo record apparso dal nulla compromettendo report finanziari calcolati.