Optimistic locking zakłada rzadkie konflikty: aktualizujesz z kontrolą wersji/timestamp i robisz retry przy konflikcie. Pessimistic locking blokuje wiersze z góry (np. `SELECT ... FOR UPDATE`), żeby inni nie mogli ich zmienić.
SELECT *
FROM accounts
WHERE id = 1
FOR UPDATE;
Odpowiedź zaawansowana
Głębiej
Oba podejścia chronią przed lost update przy współbieżności, ale „psują się” inaczej.
Optimistic locking
Bez locka na start.
Przy update sprawdzasz „czy wciąż aktualizuję tę wersję, którą odczytałem”.
Jeśli ktoś zdążył zmienić, update dotknie 0 wierszy → retry albo abort.
Przykład:
UPDATE accounts
SET balance = balance - 10, version = version + 1
WHERE id = 1 AND version = 7;
Dobre gdy:
konflikty są rzadkie,
chcesz wysokiej przepustowości,
możesz bezpiecznie robić retry.
Pessimistic locking
Najpierw blokujesz wiersz(e) (np. `SELECT ... FOR UPDATE`).
Inni będą czekać (albo dostaną błąd) do commitu/rollbacku.
Dobre gdy:
konflikty są częste,
reguły biznesowe wymagają ścisłej sekwencji,
retry jest kosztowne.
Typowe pułapki
Optimistic locking bez bezpiecznej logiki retry/idempotencji.
Pessimistic lock trzymany zbyt długo (deadlocki, spadek współbieżności).