В процессе многопользовательской работы в системе 1С:Предприятие часто возникает ситуация, когда один пользователь не может записать или изменить документ, так как он «заблокирован другим пользователем». Для разработчика и администратора важно оперативно выяснить, кто именно удерживает объект, чтобы разрешить конфликт. В этой статье мы разберем по шагам несколько способов решения этой задачи: от простых программных методов до использования инструментов платформы.
Самый простой способ, обсуждаемый практикующими разработчиками, заключается в использовании метода ЗаблокироватьДанныеДляРедактирования(). Этот метод предназначен для установки так называемой «мягкой» или интерактивной блокировки, которая обычно возникает, когда пользователь просто открывает форму объекта для редактирования.
Проанализируем ситуацию: если мы попытаемся заблокировать объект, который уже занят другим сеансом, система вызовет исключение. В тексте этого исключения платформа автоматически указывает имя пользователя, который удерживает объект. Рассмотрим пример реализации такой проверки в виде функции:
Функция ВыполнитьПопыткуБлокировки(Ссылка) Экспорт
СтруктураВозврата = Новый Структура;
СтруктураВозврата.Вставить("ОписаниеОшибки", "");
СтруктураВозврата.Вставить("Результат", Ложь);
Попытка
// Пытаемся захватить объект для редактирования
ЗаблокироватьДанныеДляРедактирования(Ссылка);
СтруктураВозврата.Вставить("Результат", Истина);
Исключение
// Если объект занят, получаем текст ошибки с именем пользователя
ОписаниеОшибки = НСтр("ru='Не удалось заблокировать для изменения %Элемент%. %ОписаниеОшибки%'");
ОписаниеОшибки = СтрЗаменить(ОписаниеОшибки, "%Элемент%", Ссылка);
ОписаниеОшибки = СтрЗаменить(ОписаниеОшибки, "%ОписаниеОшибки%", КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
СтруктураВозврата.Вставить("ОписаниеОшибки", ОписаниеОшибки);
КонецПопытки;
Возврат СтруктураВозврата;
КонецФункции
Важный нюанс: как отмечают эксперты, этот метод работает «на ура», если объект уже получен или прочитан в память. Однако стоит помнить, что после успешной проверки объект останется заблокированным вашим сеансом. Если целью была только проверка, не забудьте вызвать РазблокироватьДанныеДляРедактирования().
В современных версиях платформы 1С появилась возможность получать структурированную информацию о конфликте блокировок. Вместо парсинга строки текста ошибки мы можем обратиться к объекту ИнформацияОбОшибке.
Выясним причину блокировки более детально: при перехвате исключения в блоке Исключение можно проанализировать свойство, содержащее данные о конфликте. Платформа способна вернуть структуру, в которой будут четко разделены:
Этот метод гораздо надежнее ручного разбора строки, так как формат текстового сообщения может меняться в зависимости от локализации или версии платформы.
Рассмотрим подробнее использование метода ПолучитьИнформациюОКонфликтеБлокировок(). Он позволяет программно извлечь массив объектов, описывающих причины, по которым не удалось установить управляемую блокировку. Это особенно полезно при анализе транзакционных блокировок, которые возникают при проведении документов или записи данных в базу (когда используется объект БлокировкаДанных).
Если программные методы не подходят, или проблема носит массовый характер, проанализируем ситуацию через стандартную консоль администрирования (MMC). В разделе «Сеансы» информационный базы можно добавить колонку «Блокирует сеанс» или «Заблокировано СУБД».
В списке активных соединений сеанс, который является «виновником» ожидания других пользователей, часто выделяется длительным временем работы транзакции. Администратор может не только увидеть имя пользователя, но и при необходимости принудительно завершить его сеанс, чтобы освободить ресурсы.
Для глубокого анализа, когда нужно понять не только «кто», но и «каким кодом» была вызвана блокировка, мы используем Технологический журнал (ТЖ). Это наиболее мощный инструмент для отладки производительности.
Разберем настройку файла logcfg.xml для этих целей. Нам интересны следующие события:
TLOCK — события установки управляемых блокировок. Здесь фиксируется информация о ресурсе, пространстве блокировок и контексте исполнения кода (стек вызовов).TTIMEOUT — события превышения времени ожидания блокировки. Именно в этом событии система записывает идентификатор сеанса (wait_connections), который не дал выполнить операцию.Проанализировав эти логи, можно точно сопоставить момент возникновения ошибки в одном сеансе с действиями в другом сеансе, вплоть до конкретной строки кода 1С.
В случае использования клиент-серверного варианта и неуправляемых блокировок (или для анализа ожиданий на уровне таблиц SQL), мы можем обратиться к системным представлениям SQL Server. Выясним причину через динамические административные представления (DMV):
Использование скрипта к sys.dm_tran_locks и sys.dm_exec_requests позволяет увидеть дерево блокировок. В SQL Server можно построить запрос, который покажет «блокировщика» (Head Blocker) — сессию, которая находится в начале цепочки ожиданий. Это помогает выявить ситуации, когда один пользователь заблокировал второго, второй — третьего, и так далее.
Подведем итог: для быстрого определения «кто открыл этот документ» достаточно простого кода с ЗаблокироватьДанныеДляРедактирования. Для борьбы с серьезными блокировками при проведении документов следует использовать Технологический журнал или средства мониторинга в консоли кластера 1С.