Определите, какие изменения должны существовать вместе
Представим систему с одним свободным местом. Для бронирования нужно уменьшить число свободных мест и создать запись о брони. Если сохранить только первое изменение, место исчезнет без объяснения. Если сохранить только второе, система может продолжить показывать прежнюю доступность. Поэтому сначала формулируют условие согласованности. В нашем примере уменьшение доступности должно соответствовать созданной брони. Это правило относится к смыслу задачи, а не появляется автоматически из наличия нескольких таблиц. Транзакция объединяет операции так, чтобы их результат был принят целиком или отменён при выбранном сценарии ошибки. Такой принцип называют атомарностью. Он не означает, что внутри нет отдельных шагов; означает, что промежуточный частичный результат не должен стать окончательным состоянием операции.
Фиксация и отмена завершают работу по-разному
В явной транзакции начало отделяется от завершения. В PostgreSQL для этого используются команды BEGIN, COMMIT и ROLLBACK: начать, зафиксировать и отменить. Конкретный способ вызова зависит от приложения, но смысл остаётся различным. После успешного выполнения всех необходимых шагов фиксация принимает изменения. Если продолжать нельзя, отмена возвращает состояние изменений этой транзакции к исходному. Не следует путать отмену незавершённой работы с произвольным восстановлением любой давней версии данных. Также транзакция базы не отменяет автоматически внешние действия. Если приложение уже отправило письмо, откат записей сам по себе не заберёт сообщение из почты получателя. Поэтому связи с внешними системами требуют отдельного проектирования. Граница транзакции должна быть понятна.
Атомарность не решает все ошибки программы
Если приложение вычислило неверное число, транзакция может аккуратно сохранить именно неверное значение. Поэтому нужны проверки данных и ограничений. Целостность процесса включает правильность расчёта, а не только совместное сохранение. Одновременная работа нескольких пользователей тоже создаёт отдельные вопросы. Два обращения могут претендовать на последнее место. Наличие транзакции само по себе не позволяет игнорировать правила конкурентного доступа и выбранную изоляцию. Эти механизмы изучают вместе с конкретным сценарием. Для первой проверки удобно моделировать сбой после каждого шага. Что останется, если не удалось создать бронь? Что увидит следующий запрос? Такие вопросы показывают, какие состояния допустимы, а какие требуют отмены или другого согласованного действия. Хороший учебный пример содержит не только успешный путь. Ошибки и повторный запрос помогают обнаружить предположения, которые были скрыты в простом сценарии.
Попробуйте на практике
Проследите бронирование одного вымышленного места на бумаге.
- Запишите исходное состояние: одно свободное место и отсутствие брони. Назовите два изменения, которые должны завершиться вместе.
- Изобразите успешную последовательность и момент фиксации. Проверьте соответствие доступности и записи о брони.
- Предположите ошибку после уменьшения доступности, но до создания брони. Покажите, какое состояние должно получиться после отмены.
- Добавьте внешний шаг отправки уведомления и объясните, почему он не отменяется автоматически откатом базы. Отдельно отметьте вопрос одновременных запросов.
Как проверить результат. Успех даёт согласованное бронирование, отмена не оставляет исчезнувшее место. Граница базы и внешнего действия понятна, а атомарность не объявлена решением всех ошибок.
Частые вопросы
Транзакция проверяет правильность бизнес-логики?
Не сама по себе. Она организует выполнение изменений, но неверный расчёт или правило всё равно нужно обнаружить другими проверками.
Отмена транзакции возвращает отправленное письмо?
Нет. Внешнее сообщение находится за пределами обычного отката базы. Связь таких действий проектируют отдельно.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.