Отдельно верные шаги создают неверное сочетание
Запрос А читает остаток один. Запрос Б тоже читает один. Оба вычисляют новое значение ноль и затем записывают именно это заранее рассчитанное число. Если порядок и условия записи не защищают бизнес-правило, итоговый остаток может остаться нулём, хотя система зарегистрировала две продажи. Проверка неотрицательности остатка тогда не обнаружит расхождение: ноль допустим, но количество выданных товаров неверно. Важно описывать полную последовательность чтения, принятия решения и записи. Ошибка находится в их взаимодействии, а не обязательно в арифметике одного запроса.
Изоляция определяет видимость, но требует понимания
В PostgreSQL на уровне Read Committed обычный запрос чтения видит данные, зафиксированные до начала этого запроса. Два последовательных чтения внутри одной транзакции могут поэтому видеть разные состояния. Блокировка строки при чтении для последующего изменения помогает согласовать конкурирующие действия, но её нужно применять в пределах корректно спроектированной транзакции. Другой подход — выразить проверку доступного остатка вместе с условным изменением и учитывать, произошло ли оно. Универсальной кнопки для всех моделей нет: выбор зависит от правила, затронутых строк и допустимой конкуренции.
Надёжность проверяют через инвариант
Инвариант — условие, которое должно оставаться истинным после разрешённых операций. В примере число успешных продаж не должно превышать доступное количество. Ограничения базы данных могут защищать часть правил, а правильная организация транзакций — другую. Более строгая изоляция также способна завершать конфликтующую транзакцию ошибкой; приложение должно корректно обработать такой исход и при необходимости повторить весь соответствующий сценарий. Внешние побочные действия, например отправка уведомления, требуют отдельного учёта, чтобы повтор не создавал нежелательных дублей. Проверка должна включать конкурирующие последовательности, а не только успешный одиночный запрос.
Попробуйте на практике
Смоделируйте две продажи одного условного товара на бумаге. SQL-сервер и реальные платёжные операции для задания не нужны.
- Запишите исходный остаток один и правило: успешной может стать только одна продажа. Создайте две дорожки действий А и Б.
- Разместите сначала оба чтения единицы, затем обе записи заранее вычисленного нуля. Отдельно отметьте два ошибочно подтверждённых результата.
- Объясните, почему итоговый ноль не доказывает соблюдение правила и почему одной проверки неотрицательности недостаточно.
- Нарисуйте альтернативную последовательность, где проверка доступности и уменьшение согласованы, а второй запрос получает отказ. Укажите, какое решение защищает порядок.
- Добавьте возможную ошибку конкуренции и опишите, какие результаты нельзя сообщать как окончательные до успешного завершения транзакции.
Как проверить результат. Модель корректна, если исходная последовательность показывает две продажи при одном товаре, а исправленная допускает только одну. В объяснении должны различаться видимость данных, порядок изменений и подтверждение результата.
Частые вопросы
Почему нельзя просто проверить остаток в приложении?
Между чтением и записью другой запрос может изменить данные. Проверка должна быть связана с изменением способом, который сохраняет нужное правило при конкуренции.
Самый строгий уровень изоляции устраняет всю логику обработки ошибок?
Нет. Конфликт может привести к отмене транзакции, и приложение должно обработать её корректно. Также остаются внешние действия, модель данных и правила повторения сценария.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.