Конфликт блокировок при выполнении транзакции в 1С: что это значит и как исправить

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

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

Чаще всего ошибку видят пользователи при проведении документов, записи справочников или выполнении обменов данными. Администратору важно уметь отличать разовый конфликт (норма при параллельной работе) от системной проблемы, требующей вмешательства в код или настройки СУБД.

Что физически происходит при конфликте блокировок

Когда транзакция изменяет данные, СУБД (в клиент-серверном варианте) или платформа (в файловом) накладывает блокировку на затрагиваемые записи. Пока транзакция не завершена, другая транзакция, которой нужны те же записи, вынуждена ждать. Если время ожидания превышает допустимое (по умолчанию в 1С — 20 секунд), ожидающий сеанс получает ошибку «Превышено время ожидания предоставления блокировки».

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

Важно различать управляемые и автоматические блокировки. Автоматические платформа ставит сама при записи объектов. Управляемые разработчик устанавливает явно через объект БлокировкаДанных, и ошибки в этом коде — частая причина конфликтов: слишком широкий диапазон блокировки или блокировка «на всякий случай» целой таблицы.

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

На практике конфликты блокировок группируются вокруг нескольких повторяющихся ситуаций. Знание этих сценариев позволяет быстро сузить поиск причины.

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

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

Регламентные задания и обмены

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

Длительные транзакции в прикладном коде

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

Как диагностировать источник конфликта

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

Для глубокой диагностики в клиент-серверном варианте используется технологический журнал (ТЖ). Включите сбор событий TLOCK, TDEADLOCK и TTIMEOUT — они покажут, какие таблицы и в каком порядке блокировались, какие соединения участвовали во взаимоблокировке. Конфигурационный файл logcfg.xml размещается в каталоге conf сервера 1С.

<event><eq property="name" value="TDEADLOCK"/></event><event><eq property="name" value="TLOCK"/></event><event><eq property="name" value="TTIMEOUT"/></event><property name="all"/>

Дополнительно на стороне MS SQL Server полезны системные представления: sys.dm_tran_locks показывает текущие блокировки, sys.dm_os_waiting_tasks — ожидающие сеансы, а расширенные события (Extended Events) или трассировка позволяют зафиксировать граф взаимоблокировки. По графу видно, какие именно запросы и индексы участвуют в конфликте.

1. 1
   Зафиксируйте точное время ошибки и текст сообщения у пользователя
2. 2
   Найдите событие в журнале регистрации: пользователь, объект, сеанс
3. 3
   Сопоставьте время с расписанием регламентных заданий и обменов
4. 4
   Включите технологический журнал с событиями TLOCK, TDEADLOCK, TTIMEOUT
5. 5
   Проанализируйте собранные события: таблицы, соединения, порядок блокировок
6. 6
   На СУБД проверьте граф взаимоблокировки и участвующие запросы
7. 7
   Определите причину: код, расписание, настройки СУБД или организация работы

Способы устранения и снижения числа конфликтов

Универсального переключателя «отключить конфликты» не существует — блокировки нужны для целостности данных. Задача администратора и разработчика — сократить время удержания блокировок и уменьшить пересечение транзакций по данным.

На уровне настроек проверьте режим управления блокировкой данных в свойствах конфигурации: для большинства современных прикладных решений рекомендуется режим «Управляемый», он позволяет СУБД применять более гранулярные блокировки. На MS SQL Server убедитесь, что для базы включён READ_COMMITTED_SNAPSHOT — при нём читающие запросы не блокируются пишущими, что резко снижает число конфликтов.

ALTER DATABASE [ИмяБазы] SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;

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

Риски и ограничения

Не пытайтесь «победить» блокировки грубыми методами: принудительное снятие соединений в консоли кластера или завершение процессов на СУБД во время активной транзакции может привести к откату незавершённых операций и, при неудачном стечении обстоятельств, к рассогласованию данных. Завершать сеансы следует штатно, предупредив пользователей.

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

Типичные ошибки при борьбе с конфликтами

Ещё одна распространённая ошибка — вывод о «битой базе» по единичному сообщению. Конфликт блокировок не повреждает данные: транзакция-жертва откатывается целиком, база остаётся в согласованном состоянии. Запускать тестирование и исправление после каждой такой ошибки не нужно.

Проверка результата после внесённых изменений

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

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