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

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

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

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

Что именно блокируется и почему возникает конфликт

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

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

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

Как быстро снять блокировку прямо сейчас

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

В файловой базе посмотрите, кто ещё работает с базой (Администрирование → Активные пользователи), и попросите коллег завершить длительные операции. Если сеанс «повис» — пользователь вышел, но процесс остался — завершите процесс 1cv8 на его компьютере или перезапустите службу агента сервера в клиент-серверном варианте.

После снятия блокировки повторите операцию. Если документ провёлся без ошибки — инцидент был разовым, и углублённая диагностика не нужна.

1. 1
   Повторите операцию через 1–2 минуты — возможно, конкурирующая транзакция уже завершилась.
2. 2
   Откройте список активных сеансов и найдите сеансы с длительным временем вызова СУБД.
3. 3
   Завершите зависший сеанс через консоль кластера или попросите пользователя перезапустить программу.
4. 4
   Повторите проведение документа и убедитесь, что ошибка не возвращается.
5. 5
   Зафиксируйте время и действия пользователей — это пригодится, если конфликт повторится.

Как найти источник систематических конфликтов

Если ошибка повторяется регулярно, нужен технологический журнал. Включите сбор событий DBMSSQL (или DBPOSTGRS / DBV8DBENG) и LOCK с указанием длительности, чтобы видеть, какие запросы и блокировки конфликтуют. Файл настройки logcfg.xml размещается в каталоге conf сервера 1С.

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

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

Настройки, снижающие число конфликтов

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

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

Также проверьте настройки СУБД: для MS SQL Server рекомендуется включённый READ_COMMITTED_SNAPSHOT, при котором чтение не блокируется записями. Это существенно снижает число конфликтов между отчётами и проведением документов.

Роль кода: что проверить разработчику

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

Правильный порядок в управляемом режиме: сначала установить блокировку на конкретные диапазоны данных (объект БлокировкаДанных), затем читать и изменять их. Блокировать нужно минимально необходимый набор — конкретный товар и склад, а не весь регистр остатков.

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

Профилактика: как не допустить повторения

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

Регулярно обслуживайте СУБД: обновление статистики, перестройка индексов, контроль роста базы. Медленные запросы дольше удерживают блокировки, поэтому производительность и конфликты блокировок связаны напрямую.

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

Контрольные точки

Как проверить результат

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

Норма

Проводится без ошибок в обычное рабочее время

Тревожный признак

Ошибка возвращается — источник конфликта не устранён

Активные сеансы в консоли кластера

Норма

Нет сеансов с аномально долгим вызовом СУБД

Тревожный признак

Есть зависшие сеансы, удерживающие соединения

Технологический журнал за сутки

Норма

События LOCK с таймаутом единичны или отсутствуют

Тревожный признак

Регулярные события по одним и тем же таблицам

Расписание регламентных заданий

Норма

Тяжёлые задания выполняются вне рабочих часов

Тревожный признак

Обмены и перепроведения запускаются днём

Ответы на частые вопросы

Опасна ли ошибка конфликта блокировок для данных?

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

Почему ошибка появляется, если пользователь в базе один?

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

Поможет ли увеличение таймаута ожидания блокировки?

Это лишь маскирует проблему: пользователь будет дольше ждать и всё равно может получить отказ, а зависшие транзакции станут удерживать ресурсы дольше. Увеличение таймаута допустимо как временная мера, пока идёт поиск причины.

В файловой базе конфликты чаще — это нормально?

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

Чем конфликт блокировок отличается от взаимоблокировки?

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