В процессе разработки высоконагруженных систем на платформе 1С:Предприятие 8 программисты часто сталкиваются с необходимостью оперативного обновления данных, которые уже попали в кэш сеанса или зафиксированы в параметрах сеанса. Стандартное решение с использованием обработчиков ожидания не всегда подходит, так как оно создает лишнюю нагрузку на клиентское приложение и имеет определенную задержку. Рассмотрим, как устроены механизмы хранения этих данных и какие существуют альтернативные способы их «сброса» и обновления.
Первым делом проанализируем гипотезу о возможности прямого изменения параметров сеанса через SQL-запросы. Разберем техническое устройство платформы. Параметры сеанса — это данные, которые живут в оперативной памяти серверных процессов. В зависимости от архитектуры кластера, они обслуживаются менеджером кластера (rmngr) или рабочим процессом (rphost).
Важно понимать следующие моменты:
Таким образом, попытки «достучаться» до параметров сеанса через СУБД являются тупиковыми. Нам необходимо использовать штатные механизмы платформы.
Когда речь заходит об обращении к данным до 10 000 раз в рамках одной транзакции (например, при проведении документа), использование обычных запросов к базе может существенно замедлить работу. В этом случае программисты используют модули с повторным использованием значений. Однако у них есть проблема — кэш живет в течение времени, заданного в настройках (на время вызова или на 20 минут), и данные могут стать неактуальными.
Рассмотрим изящный способ принудительного обновления такого кэша, предложенный опытными разработчиками. Суть метода заключается в использовании Функциональных опций (ФО).
Разберем алгоритм настройки по шагам:
Константу (например, ВерсияКэшаДанных), тип которой может быть числом или строкой (например, УникальныйИдентификатор).Функциональную опцию, которая будет привязана к этой константе.Посмотрим на пример кода:
// В модуле с повторным использованием (сервер)
Функция ПолучитьАктуальныеДанные(КлючКэша) Экспорт
// Параметр КлючКэша передается только для того, чтобы платформа
// сбросила результат функции при его изменении
// Здесь выполняем тяжелый запрос или расчет
Возврат ВыполнитьРасчетДанных();
КонецФункции
Теперь проанализируем, как вызвать эту функцию из кода:
Значение = МодулиПовторногоИспользования.ПолучитьАктуальныеДанные(ПолучитьФункциональнуюОпцию("ИДКешаДанных"));
Почему это работает? Платформа 1С автоматически отслеживает изменение функциональных опций. Как только вы меняете значение константы ВерсияКэшаДанных, платформа инвалидирует кэш всех функциональных опций, связанных с ней. А поскольку значение ФО передается в функцию модуля повторного использования, система понимает, что входящий параметр изменился, и обязана вызвать функцию заново, а не брать результат из старого кэша. Это позволяет обновить данные во всех активных сеансах пользователей мгновенно при изменении одной лишь константы.
Если нам нужно обновить данные только в текущем сеансе (например, в рамках текущего серверного вызова), мы можем воспользоваться встроенным методом платформы ОбновитьПовторноИспользуемыеЗначения() (в англоязычном варианте RefreshReusableValues()).
Рассмотрим нюансы этого метода:
Выясним причину, по которой параметры сеанса могут быть не установлены. Установка параметров происходит в Модуле сеанса в обработчике УстановкаПараметровСеанса. Если в коде происходит обращение к параметру, который еще не инициализирован, платформа автоматически вызывает этот обработчик.
Если вам нужно гарантировать актуальность данных в параметре сеанса, вы можете пересчитывать их непосредственно в этом модуле. Однако помните, что расчет чего-либо для каждой строки документа (до 10 000 итераций) внутри модуля сеанса — крайне неоптимальное решение. Параметры сеанса лучше использовать для хранения статических данных (ID пользователя, его подразделение, список разрешенных складов), а для динамических расчетов внутри транзакций использовать Менеджер временных таблиц.
Проанализируем ситуацию с передачей данных между сеансами. Если система взаимодействия (Interaction System) не развернута, а актуальные данные нужны «здесь и сейчас» всем, лучшим архитектурным решением будет:
Регистр сведений.Мы рассмотрели механизмы управления кэшем в 1С и выяснили, что прямое взаимодействие с SQL для этих целей невозможно и опасно. Для решения задачи оперативного обновления данных без обработчиков ожидания рекомендуется:
ОбновитьПовторноИспользуемыеЗначения() для локальной очистки кэша в текущем контексте.Используя эти профессиональные приемы, вы сможете строить быстрые и надежные системы, обеспечивая актуальность данных даже при экстремально высоких нагрузках на информационную базу.