Какие бывают блокировки в 1С и как с ними работать

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

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

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

Объектные блокировки: оптимистичная и пессимистичная

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

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

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

Транзакционные блокировки на уровне СУБД

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

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

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

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

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

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

Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах");
ЭлементБлокировки.УстановитьЗначение("Номенклатура", Номенклатура);
ЭлементБлокировки.УстановитьЗначение("Склад", Склад);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();

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

Сеансовые и прикладные блокировки

Отдельная группа — блокировки, которые ограничивают не данные, а саму работу сеансов. К ним относятся:

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

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

Взаимоблокировки: почему возникают и как распознать

Взаимоблокировка (deadlock) возникает, когда два процесса захватили разные ресурсы и каждый ждёт освобождения ресурса другого. Например, первый документ блокирует товар А и пытается заблокировать товар Б, а второй — уже держит товар Б и ждёт товар А. СУБД обнаруживает такую ситуацию и принудительно завершает одну из транзакций с ошибкой, которую пользователь видит как «Конфликт блокировок при выполнении транзакции».

Типичные причины взаимоблокировок:

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

Диагностика: как найти, кто держит блокировку

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

Второй источник — журнал регистрации. Если включить регистрацию событий с уровнем «Ошибки» и «Предупреждения», в нём фиксируются конфликты блокировок с указанием пользователя и контекста. Для глубокого анализа используется технологический журнал с событием TDEADLOCK (взаимоблокировки) и TLOCK, а на стороне MS SQL Server — системные представления sys.dm_tran_locks и sys.dm_exec_sessions.

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

Снятие блокировок и профилактика

Зависший сеанс завершается из консоли кластера: выделите сеанс и выберите «Удалить». Если сеанс не завершается штатно, можно завершить соответствующий процесс на SQL Server, предварительно убедившись, что он не выполняет критичную длительную операцию вроде проведения тысяч документов. После аварийного завершения транзакция откатывается, и данные остаются в согласованном состоянии — это нормальное поведение СУБД.

Для профилактики конфликтов блокировок полезны следующие меры:

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

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