Рівні ізоляції

Крім явного FOR UPDATE, транзакції також мають вроджені математичні правила, закладені глибоко в механізм, які визначають, скільки енергії потрібно витрачати, ізолюючи кожну окрему взаємодію за замовчуванням. Це називається Рівнем ізоляції. In the SQL world we know 4 standard ones, in order of power and safety but obviously the inverse in terms of performance.

• READ UNCOMMITTED: Анархічне божевілля, ваша транзакція бачитиме всі зміни, внесені іншими, включно з тимчасовими даними, отриманими людьми на півдорозі до їхніх власних сценаріїв. Nobody uses it on large DBs, because of constant Dirty Read errors.
• READ COMMITTED: (за замовчуванням для Postgres). Ви миттєво побачите нові дані, щойно третя сторона видасть COMMIT, але ви можете стати жертвою фантомних зчитувань (побачивши нові записи в середині довгих робочих процесів) або нелінійного узгодженого перегляду.
• REPEATABLE READ: Важче. Під час вашої великої сесії з часовим вікном я «бачу» базу даних, заморожену на момент початку мого запиту, повністю ігноруючи й не звертаючи уваги навіть на офіційні коміти, виконані іншими людьми! It protects against records magically appearing, guaranteeing stability.
• SERIALIZABLE: Рівень Бога (Надповільний). Обробляє кожну транзакцію, що збігається, блокуючи їх і виконуючи послідовно в одній смузі, нещадно припиняючи ті, що стикаються, усуваючи в корені навіть наукову можливість найменшого зіткнення, жертвуючи 90% високої пропускної здатності.

Як це встановити?

Замість звичайного BEGIN; ви вводите:

BEGIN ISOLATION LEVEL SERIALIZABLE;

-- and you proceed normally with your hermetically sealed isolation
UPDATE products SET stock = 10;
COMMIT;

Або в деяких варіантах і старіших двигунах ви призначаєте його після запуску:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

Спробуйте самі