Blokowanie i SELECT FOR UPDATE

Zrozumienie, jak baza danych działa w izolacji na jednym terminalu, jest proste… nie, czekaj, już to mówiłem! Czasami „Aktualizacje atomowe” (np. stock = stock - 1) nie wystarczą.

Wyobraźmy sobie, że musisz sprawdzić, czy użytkownik ma wystarczające saldo, aby kupić rzeczy o wartości 50 €:

1. KODEF0
2. JS: Jeśli saldo wynosi < 50, zablokuj ich!
3. W przeciwnym razie przejdź do kasy...
4. Uruchom odliczenie! (A tutaj znajdziesz użytkownika, który podczas sprawdzania czeku w kroku 2 wystrzelił inny równoległy, który spalił jego konto i teraz spadasz poniżej zera!).

DLA AKTUALIZACJI Wyraźne blokowanie

Dodanie FOR UPDATE na końcu SELECT magicznie przekształca twój niewinny odczyt w zapieczętowaną blokadę przeciwko innym klientom aż do następnego COMMIT. Nikt inny nie będzie mógł wykonać AKTUALIZACJI (lub równoczesnego odczytu w celu aktualizacji) w tych konkretnych wybranych wierszach, dopóki nie zdecydujesz, co z nimi zrobić!

BEGIN;

-- If id=3 had already been locked by T1, T2 will sit in perpetual loading on this "read"
-- frozen in place, before receiving the raw data, until T1 runs COMMIT freeing everyone!
SELECT balance
FROM users
WHERE id = 3
FOR UPDATE;

-- at this point our Node JS instance lives with the guarantee, knowing for certain that NO ONE ELSE in the world has
-- manipulated (nor been able to read with intent to alter) that balance while we complete the application logic

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

COMMIT;

Istnieje nawet FOR SHARE, który pozwala innym czytelnikom kontynuować czytanie (jeśli są na blokadzie podstawowej) bez blokowania odczytów stanu, ale blokowania wszelkich możliwych kolejnych aktualizacji, dopóki nie zatwierdzisz. Jednak w przypadku modyfikacji zawsze używaj brutalnej siły wyłącznej klauzuli blokującej:

Spróbuj sam