Когда начинается транзакция в 1С: разбор механизмов и сценариев

Транзакция в 1С — это набор операций с базой данных, который либо выполняется целиком, либо полностью откатывается. Понимание того, в какой именно момент платформа открывает транзакцию, критично для диагностики блокировок, ошибок «Конфликт блокировок» и проблем с производительностью. Многие разработчики ошибочно считают, что транзакция существует только тогда, когда они явно вызвали НачатьТранзакцию() — на практике платформа открывает транзакции гораздо чаще.

В 1С транзакции делятся на два типа: неявные (управляемые платформой) и явные (открытые разработчиком в коде). Неявная транзакция стартует автоматически при большинстве операций изменения данных: записи документа, проведении, записи элемента справочника, выполнении обмена данными. Явная транзакция начинается только вызовом метода и требует обязательного завершения или отмены.

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

Неявные транзакции: когда платформа открывает их сама

Самый частый случай старта транзакции — интерактивная или программная запись объекта. Когда пользователь нажимает «Записать» или «Провести», платформа открывает транзакцию, выполняет все обработчики (ПередЗаписью, ПриЗаписи, ОбработкаПроведения, движения по регистрам, контроль остатков) и фиксирует изменения. Если на любом этапе возникает исключение — вся цепочка откатывается.

Неявная транзакция также открывается при установке пометки удаления, непосредственном удалении объекта, записи набора регистров и при выполнении типовых механизмов обмена данными (РИБ, универсальный формат). Важно: внутри обработчиков записи вы уже находитесь в транзакции, поэтому вызов НачатьТранзакцию() там создаст вложенную логическую транзакцию, а не новую физическую.

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

Явные транзакции: метод НачатьТранзакцию()

Явная транзакция начинается строго в момент вызова метода НачатьТранзакцию() встроенного языка. С этого момента все изменения данных накапливаются, но не фиксируются в базе, пока не будет вызван ЗафиксироватьТранзакцию(). Вызов ОтменитьТранзакцию() откатывает всё, сделанное с момента старта.

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

НачатьТранзакцию();
Попытка
    ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
    РегистрыСведений.Статусы.ЗаписатьСтатус(ДокументОбъект.Ссылка);
    ЗафиксироватьТранзакцию();
Исключение
    ОтменитьТранзакцию();
    ВызватьИсключение ОписаниеОшибки();
КонецПопытки;

Вложенные вызовы НачатьТранзакцию() не создают новых физических транзакций СУБД — платформа лишь увеличивает счётчик вложенности. Фиксация происходит только когда счётчик возвращается к нулю, то есть при сбалансированном числе вызовов «начать/зафиксировать». Отмена на любом уровне вложенности откатывает всю внешнюю транзакцию целиком.

Физическая транзакция СУБД: когда она реально открывается

В клиент-серверном варианте логическая транзакция 1С и физическая транзакция СУБД — не одно и то же. Физическая транзакция на уровне MS SQL, PostgreSQL или Oracle открывается в момент первого обращения к данным внутри логической транзакции и живёт до фиксации или отката. Именно физическая транзакция удерживает блокировки строк и таблиц.

Отсюда практический вывод: если вы открыли явную транзакцию, а затем долго выполняете вычисления без обращения к базе, блокировки ещё не установлены. Но как только внутри транзакции выполнен первый запрос или запись — блокировки захвачены и будут удерживаться до конца транзакции. Длинные транзакции с интерактивными паузами (например, ожидание ответа пользователя в модальном окне) — главный источник конфликтов блокировок.

Особые сценарии старта транзакции

Обмен данными и планы обмена

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

Фоновые задания и регламентные операции

Фоновое задание само по себе транзакцию не открывает — она стартует только при первом изменении данных или явном вызове НачатьТранзакцию(). Однако типовые регламентные задания (расчёт итогов, удаление помеченных, обмены) внутри себя работают с транзакциями, и их параллельный запуск с пользовательскими операциями — типичный источник взаимоблокировок.

Проведение документов в монопольном и управляемом режиме

При проведении документа транзакция начинается в момент вызова Записать() с режимом проведения. Внутри неё платформа последовательно блокирует регистры, по которым документ делает движения. Порядок записи регистров влияет на вероятность взаимоблокировок: если два параллельных процесса захватывают одни и те же ресурсы в разном порядке, возможна deadlock-ситуация, которую СУБД разрешит откатом одной из транзакций.

Как проверить, когда началась транзакция

Для диагностики используйте технологический журнал: включите события TLOCK, TDEADLOCK, TTIMEOUT и DBMSSQL/DBPOSTGRS с длительностью. По ним видно, в какой момент сеанс захватил блокировку и сколько удерживал. Событие EXCP с контекстом «Конфликт блокировки при выполнении транзакции» покажет оба конфликтующих вызова.

Программно проверить, находится ли код внутри явной транзакции, можно через функцию ТранзакцияАктивна() — она возвращает Истина, если есть незавершённая явная транзакция. Учтите: неявная транзакция платформы этой функцией не определяется, поэтому в обработчике записи она вернёт Ложь, хотя физически транзакция СУБД уже идёт.

Типичные ошибки при работе с транзакциями

Первая ошибка — несбалансированные вызовы: НачатьТранзакцию() есть, а ЗафиксироватьТранзакцию() или ОтменитьТранзакцию() на одной из веток логики забыли. Результат — ошибка «Нарушена последовательность вызова операций» или «висящая» транзакция до конца вызова. Всегда оборачивайте тело в Попытка/Исключение.

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

Третья ошибка — чтение данных внутри транзакции, которые затем используются для записи, без учёта того, что параллельные сеансы могут их изменить. В управляемом режиме блокировок чтение не блокирует данные, поэтому для критичных проверок (остатки, уникальность) применяйте управляемые блокировки через БлокировкаДанных или опирайтесь на контроль на уровне регистров.

Границы безопасной самостоятельной работы

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

Если конфигурация типовая и находится на поддержке, сначала ищите решение настройками (режим управляемых блокировок, разделение итогов, расписание регламентных заданий), а не изменением кода. Снятие объектов с поддержки ради правки транзакционной логики усложнит все последующие обновления.

Частые вопросы