Какие уровни изоляции транзакций существуют и как они помогают избежать проблем с конкурентным доступом?
Что проверяют
Знаете ли вы, какую конкретную аномалию снимает каждый уровень, и понимаете ли, что за строгость платят производительностью и откатами.
Как отвечать
Идите от аномалий, а не от названий.
- грязное чтение: увидели чужие незафиксированные изменения, а транзакция откатилась;
- неповторяемое чтение: прочитали строку дважды и получили разные значения, потому что между чтениями её изменили и зафиксировали;
- фантомное чтение: повторили запрос по условию и получили новые строки;
- аномалия сериализации: каждая транзакция по отдельности корректна, а вместе они оставляют базу в состоянии, которого не бывает ни при каком последовательном порядке.
Уровни снимают их по нарастающей:
- read uncommitted: не снимает ничего. В PostgreSQL фактически работает как следующий;
- read committed: нет грязного чтения. Значение по умолчанию, каждый запрос видит свой снимок;
- repeatable read: снимок один на всю транзакцию, нет неповторяемого чтения. В PostgreSQL здесь же пропадают и фантомы;
- serializable: нет и аномалий сериализации.
Цена растёт вместе со строгостью. Начиная с repeatable read PostgreSQL может отказать в фиксации с ошибкой сериализации, и приложение обязано уметь повторить транзакцию, иначе строгий уровень просто превращается в случайные пятисотки.
Где спотыкаются
Перечисляют уровни, но не могут привести пример аномалии.
Считают, что serializable это просто «надёжнее», не упоминая откаты и ретраи.
Думают, что изоляция достигается блокировками на чтение. В PostgreSQL читатели и писатели друг друга не блокируют, работает MVCC.
Ставят строгий уровень на всё приложение вместо конкретной операции, где он действительно нужен.