Locking e SELECT FOR UPDATE

Capire come funziona un database in isolamento su un singolo terminale è semplice... no aspetta, questo l'ho già detto! A volte gli "Atomic Updates" (es. stock = stock - 1) non bastano.

Immaginiamo che devi controllare se l'utente ha saldo sufficiente per comprare 50€ di roba:

1. SELECT balance FROM users WHERE id = 1;
2. JS: Se il balance è < 50, bloccatelo!
3. Altrimenti procedi con checkout...
4. Esegui la detrazione! (E qui ti trovi con un utente che mentre validava il controllo al punto 2 ne ha lanciato un altro parallelo che gli ha bruciato il conto e mo scendi sotto zero!).

FOR UPDATE Explicit Locking

Aggiungere FOR UPDATE in fondo ad un SELECT trasforma magicamente la tua innocente lettura in un lucchetto (Lock) blindato per gli altri client fino al prossimo COMMIT. Nessun altro potra' fare UPDATE (o read for updates concorrenti) su quelle specifiche righe selezionate finchè tu non decidi cosa fartene!

BEGIN;

-- Se id=3 era già stato bloccato da T1, T2 rimarrà in perenne caricamento su questa "lettura"
-- fermo immobile, prima di ricevere il dato grezzo, finchè T1 non esegue il COMMIT liberando tutti!
SELECT balance
FROM users
WHERE id = 3
FOR UPDATE;

-- a questo punto la nostra istanza JS Node vive garantita sapendo per certo che NESSUN ALTRO al mondo ha
-- manipolato (nè potuto leggere a scopo di alterare) quel saldo mentre completiamo la logica applicativa

UPDATE users SET balance = balance - 50 WHERE id = 3;

COMMIT;

Esiste perfino il FOR SHARE che lascia la possibilità agli altri lettori di continuare a leggere (se in base lock) senza impedire la lettura di stato ma bloccando però qualsiasi possibile update successivo finché non commiti. Per le modifiche però usa sempre la forza bruta della clusola lockante esclusiva:

Prova tu