Что такое конфликт блокировок в 1С и как его устранить

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

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

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

Как работают блокировки в 1С

1С использует два уровня блокировок. Первый — объектные блокировки платформы: они защищают объекты (справочники, документы) от одновременного редактирования в пользовательском интерфейсе. Если один пользователь открыл элемент для редактирования, второй увидит сообщение о том, что объект заблокирован.

Второй уровень — транзакционные блокировки СУБД (MS SQL Server, PostgreSQL). Они устанавливаются автоматически при записи данных в рамках транзакции: проведение документа, запись регистра, обмен данными. Именно на этом уровне возникают конфликты, которые пользователи видят как ошибки «превышено время ожидания» или «обнаружена взаимоблокировка».

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

Типичные причины конфликтов

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

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

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

Основной инструмент диагностики — технологический журнал (ТЖ) сервера 1С. Он фиксирует события блокировок: TLOCK (установка), TTIMEOUT (таймаут ожидания) и TDEADLOCK (взаимоблокировка). По этим событиям видно, какие сеансы, какие таблицы и какие запросы участвовали в конфликте.

Технологический журнал включается через файл настроек logcfg.xml в каталоге conf сервера 1С. Ниже пример минимальной конфигурации для сбора событий блокировок с контекстом запросов:

<config xmlns="http://v8.1c.ru/v8/tech-log"><log location="C:\1c_logs" history="24"><event><eq property="name" value="TLOCK"/></event><event><eq property="name" value="TTIMEOUT"/></event><event><eq property="name" value="TDEADLOCK"/></event><property name="all"/></log></config>

После сбора логов события TDEADLOCK покажут пару процессов и тексты запросов, а TTIMEOUT — какой сеанс кого ждал. Дополнительно полезна консоль кластера: в списке сеансов видно, какие процессы активны долгое время, а в MS SQL Server — динамические представления sys.dm_tran_locks и sys.dm_os_waiting_tasks для просмотра текущих ожиданий.

1. 1
   Включите технологический журнал с событиями TLOCK, TTIMEOUT, TDEADLOCK на период воспроизведения ошибки
2. 2
   Дождитесь повторения конфликта и зафиксируйте точное время из сообщения пользователя
3. 3
   Найдите в ТЖ события за этот момент, определите сеансы-участники и тексты запросов
4. 4
   Сопоставьте сеансы с пользователями или регламентными заданиями через консоль кластера
5. 5
   Определите таблицу и индекс, на которых возникла блокировка, и найдите в конфигурации код, формирующий эти запросы

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

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

Далее — оптимизация конкретных мест, найденных через ТЖ:

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

Частые ошибки при борьбе с блокировками

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

Вторая ошибка — включение технологического журнала с полным сбором всех событий на постоянной основе. Объём логов растёт стремительно, диск переполняется, и производительность сервера падает — к конфликтам добавляется новая проблема. Настраивайте ТЖ точечно и ограничивайте историю хранения.

Как проверить, что проблема решена

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

Ограничения самостоятельной работы

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

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

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