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

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

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

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

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

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

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

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

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

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

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

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

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

Как найти, кто держит блокировку

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

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

На стороне СУБД в MS SQL Server помогают системные представления sys.dm_tran_locks и sys.dm_exec_requests, а также Activity Monitor: по ним видно цепочки ожиданий и конкретные запросы. В PostgreSQL аналогичную картину даёт представление pg_locks в связке с pg_stat_activity.

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

Что можно сделать без привлечения разработчика

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

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

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

Меры на уровне конфигурации и кода

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

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

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

Файловый и клиент-серверный режимы: в чём разница для блокировок

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

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

Сравнение вариантов реагирования

Повторить операцию

Подходит при разовой ошибке; не решает проблему, если конфликты регулярные

Завершить зависший сеанс

Помогает, когда источник — конкретный зависший клиент; требует доступа к консоли кластера

Перенести тяжёлые задания на ночь

Устраняет конфликты с регламентными процессами; не помогает при конкуренции пользователей между собой

Оптимизация кода и режима блокировок

Единственное устойчивое решение при системных конфликтах; требует разработчика и тестирования

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

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

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

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

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

Повторение операции, вызвавшей ошибку

Норма

Операция выполняется без ошибок

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

Ошибка воспроизводится стабильно — источник не найден

События TTIMEOUT в технологическом журнале

Норма

Единичные события в периоды пиковой нагрузки

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

Десятки событий ежедневно на одних таблицах

Длительность сеансов в консоли кластера

Норма

Сеансы работают секунды, длительные — только плановые задания

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

Сеанс висит часами и удерживает соединение с СУБД

Режим управления блокировками в свойствах ИБ

Норма

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

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

Автоматический режим в клиент-серверной базе

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

Конфликт блокировки — это потеря данных?

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

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

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

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

Только как временная мера. Ошибок станет меньше, но сеансы будут дольше «висеть» в ожидании, и пользователи воспримут это как зависание программы. Если блокировка держится из-за длительного процесса, правильнее устранить сам источник, а не растягивать ожидание.

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

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

Можно ли работать в базе, пока идёт закрытие месяца?

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

Когда пора переходить с файлового режима на клиент-серверный?

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