Livelli di Isolamento

Oltre al FOR UPDATE esplicito, le transazioni hanno anche delle regole matematiche innate gestite nel profondo dell'engine relative a quanta energia impiegare per isolare di base ogni singola interazione. Questo si definisce Isolation Level. Nel mondo SQL ne conosciamo 4 standard, in ordine di potenza e sicurezza ma ovviamente inversi in fattore performance.

• READ UNCOMMITTED: Il delirio anarchico, la tua transazione vedrà tutti i dati cambiati dagli altri inclusi i dati temporanei di gente a metà dei propri script. Nessuno lo usa su grossi db, causa gli errori dei Dirty Reads continui.
• READ COMMITTED: (Default per Postgres). Vedrai istantaneamente il nuovo dato appena una terza parte ha emesso COMMIT, ma puoi finire vittima delle phantom reads (vedi nuovi record a metà dei tuoi percorsi lunghi) o in consistent view non linear.
• REPEATABLE READ: Più pesante. Per la durata della tua mega-sessione temporale "vedo" il database congelato all'istante dell'inizio della mia query, ignorando totalmente e disconoscendo anche i vari commit ufficiali completati dalle altre persone! Protegge dai record comparsi magicamente garantendo stabilità.
• SERIALIZABLE: Livello Dio (Lentissimo). Tratta ogni transazione sovrapposta bloccandole ed eseguendole serialmente in fila ad una corsia, abortendo spietatamente quelle in collissione, eliminando a radice anche la possibilità scientifica che accada anche la minima collisione, sacrificando un buon 90% dell'alto smistamento.

Come si setta?

Invece del normale BEGIN; digiti:

BEGIN ISOLATION LEVEL SERIALIZABLE;

-- e prosegui normale col tuo isolamento ermetico
UPDATE products SET stock = 10;
COMMIT;

Oppure in alcune varianti e engine vecchi lo assegni post inizio:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

Prova tu