Динамическое обновление, которое в среде разработчиков часто называют «демоническим», — это механизм, позволяющий вносить изменения в работающую базу данных без завершения сеансов пользователей. В случае с расширениями этот вопрос стоит особенно остро, так как многие считают их «легковесной» и безопасной альтернативой обновлению основной конфигурации. Однако практика показывает, что это не всегда так. В этой статье мы подробно разберем, как работает этот механизм, с какими проблемами можно столкнуться и как минимизировать риски.
Разберем внутреннюю логику платформы. Когда мы нажимаем кнопку «Обновить» для расширения при наличии активных пользователей, 1С не меняет текущую конфигурацию «на лету». Вместо этого в базе данных создается новая версия метаданных расширения. Текущие пользователи продолжают работать со старым «слепком», который был загружен в память их клиентских приложений (или rphost на сервере) в момент начала сеанса.
Проанализируем ситуацию: получается состояние неопределенности. Часть пользователей, зашедших в систему после обновления, используют новый код и структуру, а «старожилы» — старую. Это и есть главный источник большинства проблем, так как логика системы может начать конфликтовать сама с собой.
Рассмотрим пример из практики. На платформе версии 8.3.17 и выше фиксировались случаи, когда при динамическом обновлении расширения, содержащего новые реквизиты, происходила потеря данных. Если расширение добавляет в существующие объекты свои поля, платформа должна выполнить реструктуризацию таблиц СУБД. Хотя 1С старается делать это корректно, в момент динамического обновления может возникнуть критический баг. Пользователь, работающий в «старом» сеансе, может попытаться записать объект, не зная о новой структуре данных, что приводит к некорректному обновлению записей в таблицах.
Важно: Если ваше расширение меняет структуру данных (добавляет реквизиты, таблицы, измерения), риск «положить» базу или потерять данные при динамическом обновлении возрастает многократно. В таких случаях настоятельно рекомендуется использовать только монопольный режим.
Выясним, почему после обновления пользователи часто жалуются на странное поведение системы. Основная причина — некорректная очистка кэша. Платформа должна автоматически уведомлять клиентское приложение о необходимости обновить версию конфигурации, но этот механизм срабатывает не всегда.
Разберем основные последствия проблем с кэшем:
ХранилищеНастроек: Формы могут перестать открываться или отображаться некорректно, так как старые настройки компоновки или пользовательские настройки формы конфликтуют с измененным кодом расширения.rphost может удерживать в оперативной памяти старые скомпилированные модули. Это приводит к тому, что клиент вызывает метод, ожидая нового поведения, а сервер отрабатывает по старой логике.Проанализируем работу фоновых заданий, которые являются наиболее уязвимым местом. В отличие от интерактивного пользователя, фоновое задание не может «увидеть» сообщение о необходимости перезапуска. Если задание было запущено до момента обновления расширения, оно гарантированно будет использовать старый код до момента своего завершения.
Представим ситуацию: расширение меняет алгоритм расчета себестоимости в процедуре проведения документа. Если в этот момент выполняется регламентное задание по перепроводке, часть документов будет проведена по старой логике, а часть (запущенная после обновления) — по новой. Это создает трудноуловимые ошибки в учете, которые могут быть обнаружены только спустя долгое время.
Многие современные конфигурации (УТ 11, ERP, БП 3.0) построены на базе БСП. Эта библиотека хранит информацию о версиях установленных расширений в своих внутренних регистрах. Рассмотрим технический нюанс: при динамическом обновлении расширения регистрация изменений в БСП часто не происходит должным образом.
В итоге система может «не заметить» обновление и не запустить необходимые обработчики обновления данных (UpdateHandlers). Это критично, если новая версия расширения требует заполнения каких-то новых констант или регистров сведений при первом запуске.
Если ваша система активно использует интеграции через веб-серверы (Apache или IIS), динамическое обновление расширений становится еще опаснее. Веб-сервер кэширует описание метаданных WSDL. После обновления расширения структура сервиса может измениться в базе данных, но веб-сервер будет продолжать отдавать старую структуру. Это часто приводит к ошибкам 500 Internal Server Error или 404 Not Found. В таких случаях помогает только ручной перезапуск службы веб-сервера.
Посмотрим на алгоритм, который поможет минимизировать риски, если избежать динамического обновления невозможно:
%AppData%\1C\1Cv8 у пользователей.Для гарантированной чистоты обновления мы можем использовать следующий программный прием для проверки версии расширения в коде:
// Пример проверки версии расширения для предотвращения рассинхрона
ВерсияРасширения = РасширенияКонфигурации.Найти("МоеРасширение").Версия;
Если ВерсияРасширения <> ОжидаемаяВерсия Тогда
Сообщить("Внимание! Используется неактуальная версия расширения. Перезайдите в систему.");
КонецЕсли;
Безопасно ли динамическое обновление расширений? Нет, оно не является абсолютно безопасным. Хотя платформа 1С делает многое для обеспечения стабильности, человеческий фактор, особенности работы сетевых протоколов и кэширования серверных процессов могут привести к сбоям.
Помните: можно успешно обновиться 100 раз, но на 101-й получить повреждение базы данных или потерю данных в реквизитах. Если стабильность системы и целостность данных являются приоритетом, старайтесь планировать технологические окна для монопольного обновления расширений.