Краткий ответ

При автокоммите каждый отдельный оператор обычно выполняется в собственной транзакции и автоматически фиксируется после успешного завершения. Поэтому успешное изменение заказа может остаться зафиксированным, даже если следующий оператор уменьшения остатка завершился ошибкой. Чтобы оба изменения были одной атомарной операцией, их нужно явно включить в одну транзакцию.

Исторический контекст

Транзакционная модель SQL должна поддерживать как короткие одиночные операции, так и последовательности действий, которые необходимо фиксировать совместно. Автокоммит появился как удобный режим для независимых запросов: разработчику не требуется явно начинать и завершать транзакцию вокруг каждого простого изменения.

Компромисс состоит в том, что удобство одиночных операций не означает автоматического объединения соседних операторов. Граница транзакции определяется правилами конкретного режима работы соединения и СУБД, поэтому приложение должно явно задавать границу для многошаговой бизнес-операции.

Постановка проблемы

Рассмотрим оформление заказа: сначала создаётся запись заказа, затем резервируется товар. Если создание заказа уже зафиксировано, а резервирование не удалось из-за отсутствия товара, база может оказаться в промежуточном состоянии: заказ существует, но соответствующий резерв отсутствует.

Такое состояние опасно для последующей логики. Повторный запуск может создать дубликат заказа, а фоновая обработка может принять уже созданный заказ за корректно оформленный.

Подробное решение

При автокоммите успешный оператор становится отдельной завершённой транзакцией. Если следующий оператор завершается ошибкой, откатывается только его собственная транзакция; ранее зафиксированные изменения не возвращаются автоматически.

Для атомарного сценария приложение должно явно начать транзакцию до первого изменения и завершить её фиксацией только после успешного выполнения всех шагов. При любой ошибке выполняется откат всей транзакции, включая уже выполненные в ней операторы.

BEGIN;
INSERT INTO orders(id, customer_id) VALUES (101, 7);
UPDATE products
SET stock = stock - 1
WHERE id = 55 AND stock > 0;
-- Если обновлено 0 строк, приложение выполняет ROLLBACK.
COMMIT;

Сам по себе оператор UPDATE с условием не гарантирует, что бизнес-операция завершилась успешно: приложение должно проверить, была ли изменена ожидаемая строка. Если остаток равен нулю, следует откатить транзакцию, а не фиксировать созданный заказ.

Явная транзакция также задаёт более длительное время удержания блокировок и версий данных. Поэтому не следует включать в неё сетевые вызовы, ожидание действий пользователя или тяжёлые вычисления без необходимости: это увеличивает вероятность блокировок, конфликтов и взаимного влияния транзакций.

Точное поведение автокоммита, особенно для DDL и специальных операторов, зависит от СУБД. Нельзя переносить правила одной системы на другую без проверки документации, но общий принцип границы транзакции для обычных DML-операторов сохраняется: отдельные автокоммитные операторы не образуют единую атомарную бизнес-операцию.

Ситуация из практики

Сервис оплаты сначала помечал платёж как созданный, а затем резервировал товар отдельным запросом. При конкурирующем заказе резервирование иногда завершалось ошибкой, однако платёжный заказ уже был зафиксирован и попадал в отчёты как полноценный.

Рассматривались два варианта. Удалять созданный заказ отдельным компенсирующим запросом было проще внедрить, но такой подход сам мог завершиться ошибкой и требовал фоновой сверки. Перевести оба изменения в одну явную транзакцию было надёжнее с точки зрения атомарности, хотя это увеличивало длительность транзакции и требовало тщательно ограничить её границы.

Выбрали явную транзакцию с проверкой результата резервирования и откатом при недостаточном остатке. Внешние вызовы вынесли за пределы транзакции, а повторную обработку сделали идемпотентной. В результате неуспешное резервирование больше не оставляло зафиксированный заказ в состоянии, которое выглядело как успешно оформленное.

Что кандидаты часто упускают

1. Вопрос: Означает ли автокоммит, что каждый оператор всегда выполняется вне транзакции?

Ответ: Нет. Автокоммит обычно означает автоматическое завершение транзакции после оператора, но сам оператор всё равно выполняется в транзакционном контексте. Если оператор завершился ошибкой, его изменения обычно откатываются; если успешно — фиксируются автоматически. Конкретные исключения и поведение отдельных типов операторов зависят от СУБД.

2. Вопрос: Можно ли надёжно начать транзакцию в одном запросе приложения, а завершить её в другом HTTP-запросе?

Ответ: Обычно это ненадёжно. Транзакция привязана к конкретному соединению с базой, а пул соединений может выдать второму HTTP-запросу другое соединение. Кроме того, длительное удержание транзакции на время пользовательского взаимодействия расходует соединения и блокировки. Обычно транзакцию ограничивают одной короткой серверной операцией, а её повторяемость обеспечивают идемпотентностью и сохранением промежуточного состояния.

3. Вопрос: Что произойдёт, если ошибка возникла после первого изменения, но приложение продолжило выполнять операторы в той же явной транзакции?

Ответ: Это зависит от СУБД и типа ошибки. Во многих системах после ошибки транзакция переходит в состояние, в котором дальнейшие операторы, кроме отката, запрещены или не имеют ожидаемого эффекта. Безопасная стратегия — обработать ошибку, выполнить полный откат и при необходимости повторить всю бизнес-операцию, а не считать транзакцию успешно продолжающейся.