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

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

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

Дальше разберём, какие бывают блокировки, как найти виновника конфликта, что сделать немедленно и как снизить вероятность повторения ошибки в файловой и клиент-серверной базе.

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

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

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

Виды блокировок в 1С

Платформа использует два режима управления блокировками, и от режима зависит частота конфликтов.

Автоматический режим

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

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

В управляемом режиме разработчик явно указывает в коде, какие данные блокировать и когда. Блокировки накладываются точечно — по конкретному товару, складу, контрагенту. Современные типовые конфигурации (ERP, УТ 11, БП 3.0, ЗУП 3.1) рассчитаны на управляемый режим, и в свойствах конфигурации он обычно установлен как «Управляемый» или «Автоматический и управляемый».

Сравнение режимов блокировок

Автоматический режим

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

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

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

Смешанный режим

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

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

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

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

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

Первый инструмент — список активных пользователей. В клиенте 1С: «Администрирование → Обслуживание → Активные пользователи». Здесь видно, кто сейчас в базе, когда начался сеанс и как долго он бездействует. Сеанс, открытый много часов назад и «висящий» без активности, — главный подозреваемый.

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

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

Что сделать немедленно, чтобы разблокировать работу

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

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

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

Особенности файловой и клиент-серверной базы

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

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

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

Как снизить количество конфликтов в будущем

Разовое снятие блокировки не решает проблему, если она системная. Работайте в нескольких направлениях.

• Проверьте режим блокировок конфигурации. Для многопользовательской работы должен использоваться управляемый режим; если конфигурация старая или сильно доработана, привлеките разработчика для перевода проблемных объектов.
• Разнесите нагрузку по времени. Перепроведение, закрытие месяца, обмены и тяжёлые отчёты планируйте на нерабочие часы.
• Сокращайте транзакции. Чем меньше действий внутри одной транзакции, тем короче блокировка. Документы на тысячи строк лучше разбивать.
• Ведите дисциплину сеансов. Настройте автоматическое завершение неактивных сеансов, обучите пользователей закрывать программу, а не сворачивать её на ночь.
• Аудируйте доработки. Внешние обработки и расширения с незакрытыми транзакциями — частый источник «вечных» блокировок.

Частые вопросы о конфликте блокировок в 1С

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

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

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

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

Что делать, если зависший сеанс не завершается?

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

Можно ли увеличить время ожидания блокировки, чтобы ошибка не появлялась?

Технически таймаут ожидания настраивается, но это маскирует проблему, а не решает её: пользователи будут дольше ждать «зависшей» программы вместо быстрой ошибки. Увеличение таймаута оправдано только как временная мера на период поиска и устранения причины.

Нужно ли переходить на клиент-серверный вариант из-за блокировок?

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

Кто должен устранять системные конфликты — администратор или разработчик?

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