tgoop.com/Java_Iibrary/1734
Last Update:
Уровни изоляции в базах данных за 5 минут
ACID описывает свойства, гарантирующие надежность транзакций. Но даже если СУБД заявляет поддержку ACID, по умолчанию она может использовать более слабый уровень изоляции.
Разным приложениям нужно разное, где-то важна скорость и можно потерпеть небольшие несостыковки, а где-то критична строгая целостность данных. Проблема в том, что параллельное выполнение транзакций без контроля ведет к аномалиям: dirty read, non-repeatable read, phantom read
Уровни изоляции определяют, насколько одна транзакция защищена от последствий других, выполняющихся одновременно.
• Read Uncommitted (минимальный уровень)
Транзакции вообще не изолированы. Видно изменения других транзакций даже до их коммита. Это может привести к dirty reads.
• Read Committed
Транзакция видит только закоммиченные данные. Dirty reads исключены, но non-repeatable reads остаются возможны.
• Repeatable Read
Транзакция работает с "замороженным снимком" базы на момент старта. Изменения других транзакций ей не видны. Реализация бывает через блокировки (shared locks) или MVCC (мультиверсии строк). Это убирает non-repeatable reads.
• Serializable
Максимальная строгость. Всё выглядит так, будто транзакции идут последовательно одна за другой. Для этого применяются жесткие блокировки вроде range/predicate locks.
Чем выше уровень изоляции, тем больше гарантий целостности, но тем сильнее удар по производительности. Нужно выбирать баланс под конкретную задачу.
