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