Condiții de cursă

Înțelegerea modului în care funcționează o bază de date izolată pe un singur terminal este simplă, dar într-un scenariu web real vor exista sute de procese simultane „Node/PHP/Go” care trimit cereri. Aici se nasc faimoasele Condiții de cursă.

Problema „Actualizare pierdută”.

Actualizarea pierdută se întâmplă atunci când două fire citesc același rând vechi, fac niște calcule pe el pe serverul JavaScript și apoi trimit înapoi UPDATE pentru a salva rezultatul.

Scenariu:

• Produsul #5 are 10 unități.
• Utilizatorul A cumpără unul (Serverul A citește „10”, calculează „9”).
• În aceeași milisecundă utilizatorul B cumpără altul înainte ca achiziția lui A să termine faza COMMIT.
• Serverul B citește și „10”, calculează „9”.
• Serverul A trimite UPDATE: set quantity = 9.
• Serverul B trimite UPDATE: set quantity = 9.
• Ambii cred că au scăzut numărul cu succes. Dar valoarea finală ar fi trebuit să fie de 8 unități! O achiziție fantomă a fost pierdută.

Soluție fără tranzacții grele (Actualizări atomice)

În loc să citiți și să faceți calcule afară, lăsați DB să o facă în timpul actualizării în sine, care este întotdeauna sincronizată.

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

-- Correct and natively thread-safe
UPDATE products SET stock = stock - 1 WHERE id = 5;

Mai multe anomalii extreme (Dirty Reads & Phantoms)

• Dirty Read: ați citit datele temporare ale altcuiva care nu au fost încă confirmate de un COMMIT (și ar putea trece brusc la ROLLBACK, invalidându-vă).
• Citituri fantomă: Faceți o scanare a tuturor rândurilor, între timp un al doilea thread inserează o nouă înregistrare, apoi faceți o altă scanare în timpul aceleiași tranzacții și descoperiți ca magic că noua înregistrare a apărut de nicăieri, compromițând rapoartele financiare calculate.