Ситуация, когда при обновлении информационной базы (особенно при переходе на новые версии Библиотеки стандартных подсистем) система выдает ошибку монопольного доступа, указывая на ваш же собственный сеанс, является довольно распространенной и коварной. Особенно часто это проявляется в файловом режиме работы 1С. Рассмотрим подробно, почему возникает ошибка УстановитьМонопольныйРежим, когда в базе нет других пользователей, и как с этим бороться.
В нашем случае ключевым фактором является выборочное обновление подсистем БСП (например, только Адресного классификатора). Начиная с версии 2.4, механизмы обновления в БСП претерпели значительные изменения. Подсистемы стали более тесно взаимосвязаны на уровне базовых модулей.
Проанализируем ситуацию: если при ручном переносе объектов из новой версии БСП в вашу конфигурацию был пропущен хотя бы один фрагмент кода в общих модулях, таких как ОбновлениеИнформационнойБазы или СтандартныеПодсистемыСервер, это может привести к нарушению логики транзакций. Проблема часто кроется в том, что система пытается вызвать процедуру УстановитьМонопольныйРежим() в тот момент, когда еще не завершена транзакция, открытая предыдущим обработчиком обновления. В платформе 1С:Предприятие невозможно установить монопольный режим внутри активной транзакции.
Автор темы отмечает, что ошибка стабильно возникает после выполнения 8% обработчиков. Это критическая точка. Разберем, что происходит в этот момент. Обычно в начале процесса обновления выполняются так называемые критические обработчики, которые обязаны работать в монопольном режиме. После их завершения система пытается переключиться в режим обычного доступа для выполнения отложенных (некритических) обработчиков. Для точечной диагностики и поэтапного выполнения процедур можно использовать обработку для запуска процедур обновления в конфигурациях на БСП.
Если на этом этапе логика «переключения» режимов дает сбой (например, из-за конфликта с фоновым заданием, которое платформа в файловом режиме ошибочно приписывает основному сеансу), мы получаем ошибку разделенного доступа. Посмотрим на пример кода, который может вызывать подобное поведение, если он встроен в цепочку обновления некорректно:
// Пример фрагмента, который может вызвать ошибку в файловой базе
Попытка
УстановитьМонопольныйРежим(Истина);
Исключение
// В файловом режиме здесь часто возникает ошибка,
// если активен фоновый процесс «имитации сервера»
ЗаписатьЛогСобытия("Ошибка монопольного доступа: " + ОписаниеОшибки());
КонецПопытки;
Современные версии платформы 8.3 даже в файловом режиме имитируют клиент-серверную архитектуру. Это означает, что при запуске системы могут автоматически стартовать служебные процессы, которые не видны в обычном списке активных пользователей, но блокируют таблицы 1Cv8.1CD.
Проанализируем основные факторы «невидимых» блокировок:
Если стандартные советы (очистка кэша, перезагрузка, использование толстого клиента) не помогают, воспользуемся более глубокими методами исправления ситуации.
Шаг 1: Принудительное сжатие таблиц
В файловой базе данных физическая структура файла может содержать «зависшие» пометки о блокировках на уровне страниц данных. Обычное тестирование и исправление (проверка ссылок) здесь не поможет. Нужно выполнить именно Сжатие таблиц через утилиту chdbfl.exe или через конфигуратор. Это пересоберет файл базы данных и гарантированно удалит мусорные блокировки.
Шаг 2: Контроль транзакций в коде
Рассмотрим возможность модификации кода в месте возникновения ошибки. Перед вызовом метода УстановитьМонопольныйРежим полезно добавить проверку на наличие активной транзакции. Если транзакция активна, ее нужно завершить или отменить, прежде чем запрашивать монопольный доступ.
// Диагностика состояния транзакции перед блокировкой
Если ТранзакцияАктивна() Тогда
// Это и есть причина ошибки. Нужно найти, где транзакция началась и не закрылась.
ТекстСообщения = "Обнаружена незавершенная транзакция перед установкой монопольного режима!";
ЗаписатьЖурналРегистрации("ОбновлениеИБ", УровеньЖурналаРегистрации.Предупреждение,,, ТекстСообщения);
// ОтменитьТранзакцию(); // Крайняя мера для диагностики
КонецЕсли;
Шаг 3: Отключение блокировки регламентных заданий в коде
Иногда при программном обновлении через ключ /C ЗапуститьОбновлениеИнформационнойБазы возникает конфликт с константой ПараметрыБлокировкиСеансов. Проверьте, чтобы в коде БСП параметр AllowExecuteScheduledJobs (Разрешить выполнение регламентных заданий) был установлен в значение Ложь именно в момент перехода к критическим фазам обновления. Для оперативной настройки расписания фоновых процессов можно применить обработку для управления регламентными заданиями в БСП.
Поскольку мы работаем с файлом 1Cv8.1CD, нельзя исключать влияние операционной системы. Разберем два наиболее частых случая:
Подводя итог, можно сказать, что самоблокировка сеанса при обновлении БСП 2.4 — это чаще всего следствие незавершенной транзакции в одном из предыдущих обработчиков или результат работы скрытых фоновых процессов платформы в файловом режиме. Для успешного завершения процесса рекомендуем:
ОбновлениеИнформационнойБазы*.