Уровни изоляций. Честно, я первый раз про них узнал на собесах. Меня спросили, я продолбался и пошёл читать. Разобраться — разобрался, но ещё долго думал, что они нужны только для того, чтобы на собесах отвечать 🌟 Если того же мнения — велком. Сначала на пальцах разберёмся что это такое, а затем — зачем вообще уметь их настраивать https://youtu.be/_IVRzj94z4w

Вчерашний квиз: правильно ответили 38% 🥰 Останется 70. 25% выбрали 40, и бухгалтерия с ними согласна: списали дважды по 30. А в базе 70: клиент потратил 60, заплатил 30. Представь копилку и тетрадку, где записан остаток. Двое одновременно заглянули в тетрадку: 100. Каждый взял из копилки 30 и написал "осталось 70". В копилке 40, в тетрадке 70. Арифметика верная, просто второй переписал первого. Почему Read Committed не спас? Он обещает одно: ты не прочитаешь то, что другой ещё не закоммитил. Оба прочитали закоммиченные 100. От "прочитал, посчитал, записал" он не защищает. Ошибку (23%) дал бы Repeatable Read: Postgres увидит, что строку поменяли после чтения, и ответит второму ошибкой 40001. Её надо ловить и повторять. "Как повезёт" (14%) тоже мимо: оба успели прочитать, поэтому 70 каждый раз. А теперь обычный код на EF: var account = db.Accounts.Single(a => a.Id == id); account.Balance -= 30; db.SaveChanges(); В базу уходит SET "Balance" = @p0, и в @p0 лежит 70. EF шлёт готовое число, а не вычитание 🔥 db.Accounts.Where(a => a.Id == id) .ExecuteUpdate(s => s.SetProperty(a => a.Balance, a => a.Balance - 30)); Здесь уходит "Balance" - 30. Второй запрос ждёт первый, перечитывает строку и списывает уже с 70. Итог 40. Транзакция не спасает от гонки, если считаешь в памяти. Считай в базе. Поищи у себя Balance -=. Я подожду 🫡