Изоляция — свойство взаимодействия транзакций. Уровень изоляции — выбранный режим конкретной реализации. Одинаковая деловая операция может дополнительно требовать условной записи или явной блокировки, поэтому её проверяют целиком.
Практический смысл
Почему это важно
Два покупателя могут одновременно попытаться забрать последний сервер. Важны порядок проверки и записи, выбранный уровень и обработка конфликта. Сначала докажите корректность этой операции, затем измеряйте ожидание, повторы и скорость. Более слабый уровень не даёт универсального выигрыша производительности, а дополнительный CPU не исправляет ошибочный порядок действий.
Доказательная часть
Что подтверждено
Изоляция определяет допустимое взаимодействие параллельных транзакций. Уровни SQL различаются по разрешённым аномалиям; название уровня следует читать вместе с гарантией конкретной реализации, а не как общее обещание одинаковой видимости во всех СУБД.
Граница применимости: Модель параллелизма транзакций и таблица аномалий в документации PostgreSQL 18.
Изоляция отвечает за взаимодействие параллельных транзакций. Долговечность отвечает за сохранение зафиксированного результата после предусмотренного отказа. Тест двух конкурентных заказов не проверяет сохранность после сбоя, а успешное восстановление не доказывает правильную изоляцию.
Граница применимости: Разделение свойств I и D в модели ACID; испытательные примеры иллюстрируют разные условия проверки.
Запрет грязного чтения не исключает аномалию сериализации: транзакции могут читать только зафиксированные данные, но совместно получить результат, неэквивалентный последовательному выполнению. PostgreSQL 18 допускает такие аномалии на Read Committed и Repeatable Read.
Граница применимости: PostgreSQL 18, уровни изоляции и аномалия сериализации; не утверждение о каждом конкретном исполнении.
В PostgreSQL 18 на Read Committed UPDATE, ожидавший конкурирующее изменение строки, повторно проверяет условие отбора на её обновлённой версии. Для одного остатка условие «остаток не меньше количества» можно включить в само уменьшение; после ожидания второй покупатель может получить ноль изменённых строк.
Граница применимости: Редакторский пример PostgreSQL 18: одна строка товара, положительное количество и UPDATE остатка с проверкой достаточности в WHERE. Не доказательство правил, охватывающих несколько строк.
SELECT FOR UPDATE в PostgreSQL 18 блокирует выбранные строки от конкурирующих изменений и несовместимых блокировок до окончания транзакции. Это позволяет согласовать проверку и изменение существующего остатка; блокировка выбранной строки сама по себе не защищает произвольное правило по другим строкам.
Граница применимости: PostgreSQL 18, блокировки строк; речь о выбранных существующих строках и обычном завершении транзакции, без частичного отката к точке сохранения.
После отказа сериализации в PostgreSQL 18 нужно повторять всю транзакцию, включая чтения и вычисление решения. Повтор только последнего UPDATE сохраняет выводы, сделанные по прежним данным, и не выполняет требование заново построить согласованную операцию.
Граница применимости: PostgreSQL 18, обработка serialization failure на Repeatable Read или Serializable; внешние действия требуют самостоятельного безопасного контракта повторов.
Граница терминов
Не путать
Изоляция определяет, какие конкурентные результаты допустимы. Долговечность определяет, какие принятые результаты должны пережить оговорённый отказ. Настройка ожидания WAL не устраняет аномалию сериализации, а более строгая изоляция не заменяет устойчивое хранение.
Перед спецификацией
Что проверить
- Запишите общий запрет для двух заказов: например, нельзя продать больше единиц, чем есть в одной строке остатка.
- В двух сеансах выполните чтения и изменения в заранее заданном порядке, чтобы конфликт воспроизводился.
- Проверьте фактический уровень изоляции каждой транзакции, а не только настройку подключения по умолчанию.
- Если используется условный UPDATE, проверяйте число изменённых строк и не подтверждайте продажу при нуле.
- Если используется SELECT FOR UPDATE, убедитесь, что чтение и последующая запись находятся в одной транзакции и что известна область блокировки.
- Вызовите отказ сериализации и проверьте повтор всей операции вместе с исходными чтениями.
- Измерьте ожидания блокировок, число повторов и задержку на реальном распределении заказов; не выводите выигрыш только из названия уровня.
Открытые основания
Первоисточники
The Transaction Model — Turing Award Lecture
Microsoft Research / ACM · Jim Gray, FCRC 1999 lecture slides
Первичный обзор transaction model, ACID, concurrency anomalies, logs и two-phase commit.
Открыть первоисточникPostgreSQL 18 Documentation: Transaction Isolation
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 13.2
Определяет isolation phenomena и фактическое поведение PostgreSQL levels, включая Serializable.
Открыть первоисточникPostgreSQL 18 Documentation: Explicit Locking
PostgreSQL Global Development Group · документация PostgreSQL 18, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить блокировки строк SELECT FOR UPDATE, ожидание конкурирующих изменений и срок удержания до конца транзакции.
Открыть первоисточникPostgreSQL 18 Documentation: Write-Ahead Logging
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 28.3
Определяет write-ahead rule, REDO crash recovery и роль checkpoint.
Открыть первоисточник