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

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

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

Ниже разобраны причины конфликтов, способы найти источник блокировки и конкретные действия для администратора и разработчика: от настройки режима управляемых блокировок до переработки кода проведения.

Почему возникает конфликт блокировок

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

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

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

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

Как определить источник конфликта

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

Дополнительно полезен мониторинг на стороне СУБД: в MS SQL Server — представления sys.dm_tran_locks и отчёты по блокировкам, в PostgreSQL — pg_locks и pg_stat_activity. Они показывают, какой сеанс держит блокировку и кто ожидает.

В клиент-серверном варианте проверьте консоль кластера: список сеансов и соединений покажет, какие пользователи или фоновые задания активны в момент ошибки. Часто виновником оказывается регламентное задание обмена, совпадающее по времени с пиковой работой пользователей.

Быстрые способы снизить число конфликтов без доработки

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

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

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

1. 1
   Повторите операцию — разовый конфликт часто не повторяется
2. 2
   Зафиксируйте время и пользователей, у которых возникла ошибка
3. 3
   Сопоставьте время с расписанием регламентных заданий и обменов
4. 4
   Перенесите тяжёлые задания на нерабочие часы
5. 5
   Разбейте массовые обработки на порции
6. 6
   Включите техножурнал с TLOCK для сбора фактов

Перевод конфигурации на управляемые блокировки

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

Переключение режима — не просто смена свойства. Код, написанный под автоматический режим, может полагаться на то, что прочитанные в транзакции данные не изменятся. В управляемом режиме контроль остатков нужно выполнять явно: читать остатки после установки блокировок или использовать конструкцию «ДЛЯ ИЗМЕНЕНИЯ» в запросах.

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

Доработка кода для устранения конфликтов

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

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

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

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

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

Настройки СУБД и инфраструктуры

На уровне MS SQL Server проверьте, что для базы включён READ_COMMITTED_SNAPSHOT (версионность): при нём читающие запросы не блокируются пишущими, что заметно снижает число конфликтов. Для PostgreSQL это поведение стандартно, но важно следить за длинными транзакциями и автовакуумом.

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

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

Сравнение подходов

Организационные меры (расписания, регламенты)

Быстро и без риска, но не устраняет причину; подходит как временное решение

Управляемый режим блокировок

Системное решение для многопользовательской работы; требует анализа и доработки кода

Явные блокировки и доработка кода

Точечно снимает узкие места; требует квалификации разработчика и тестирования

Настройка СУБД (версионность, индексы)

Снижает общий уровень конкуренции; не помогает при ошибках в логике транзакций

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

После внесения изменений соберите статистику: количество событий TLOCK в техножурнале за типовой рабочий день до и после изменений. Устойчивое снижение числа конфликтов при той же нагрузке — объективный признак результата.

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

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

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

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

События TLOCK в техножурнале

Норма

Единичные случаи или отсутствуют

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

Регулярные конфликты в часы пик

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

Норма

Проводится с первой попытки

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

Пользователям приходится повторять операции

Остатки после доработок

Норма

Сходятся с данными до изменений

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

Расхождения, отрицательные остатки

Время отклика в часы пик

Норма

Приемлемое ожидание без ошибок

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

Долгие зависания сеансов

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

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

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

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

FAQ

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

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

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

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

Поможет ли переход с файловой базы на клиент-серверную?

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

Что делать, если конфликт возникает только во время обмена данными?

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

Можно ли полностью избавиться от конфликтов блокировок?

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

Нужно ли привлекать разработчика или достаточно настроек администратора?

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