Більшість розробників, які працюють з реляційними базами даних кілька років, можуть назвати чотири стандартні рівні ізоляції. Набагато менше з них можуть пояснити, чому в їхньому конкретному застосунку обраний саме Read Committed, а не Repeatable Read - і чи це взагалі свідоме рішення.
Проблема замовчування
Read Committed - рівень за замовчуванням у PostgreSQL і більшості інших СУБД. Він підходить для широкого кола задач, але не для всіх. Якщо ваш застосунок читає дані кілька разів у межах однієї транзакції і очікує їх незмінності - ви вже маєте проблему, навіть якщо ще не бачили її симптомів.
Де це реально ламається
Фінансові розрахунки, де баланс рахунку читається двічі. Генерація звітів, де агрегати мають бути консистентними. Логіка резервування, де перевірка наявності і запис відбуваються в одній транзакції. У всіх цих випадках Read Committed може повернути некоректний результат без жодної помилки - просто тихо.
- Serializable дає найсильніші гарантії, але коштує дорого при високій конкурентності
- Repeatable Read захищає від non-repeatable reads, але не від phantom reads у деяких реалізаціях
- Вибір рівня ізоляції - архітектурне рішення, а не налаштування за замовчуванням
Початківець не знає про ці нюанси. Досвідчений знає, але рідко переглядає рішення, прийняті роки тому при проектуванні схеми.