Как правильно обновлять данные в модулях повторного использования при изменении условий?

При использовании модулей повторного использования часто возникает архитектурная задача: как сделать так, чтобы кэшированные данные обновлялись не только в рамках текущего сеанса, но и во всей информационной базе, если изменились условия, влияющие на результат функции?

Понимание проблемы инвалидации кэша

Механизм повторного использования в платформе 1С предназначен для ускорения работы системы путем сохранения результата выполнения функции в кэше сервера. Однако этот кэш не всегда «знает», когда данные, на основе которых был сформирован результат, изменились.

Метод ОбновитьПовторноИспользуемыеЗначения(), который часто вспоминают разработчики, работает исключительно в пределах одного сеанса. Это значит, что если вы выполнили его в одной сессии, данные в других сеансах останутся прежними до истечения времени жизни кэша или перезагрузки рабочего процесса. Для распределенных систем этот метод не подходит.

Способ №1: Использование параметров функции как «триггеров»

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

Рассмотрим, как реализовать этот подход на практике:

1. Создайте константу, которая будет хранить текущий «идентификатор версии» (например, дату-время последнего изменения или уникальный идентификатор).
2. В функции модуля повторного использования добавьте параметр, принимающий этот идентификатор.
3. При вызове функции из кода системы передавайте значение этой константы.

Когда данные изменяются, вы обновляете значение константы. Платформа видит новый набор параметров (функция + новый аргумент) и автоматически выполняет функцию заново, сохраняя новый результат в кэш. Старые записи в кэше со временем вытеснятся.

// В модуле повторного использования
Функция ПолучитьУзлыОбмена(ИдентификаторВерсии) Экспорт
    // Запрос выполняется только при изменении переданного параметра
    Запрос = Новый Запрос;
    Запрос.Текст = "...";
    Возврат Запрос.Выполнить().Выгрузить();
КонецФункции

// Вызов функции в коде
Идентификатор = Константы.ВерсияНастроекОбмена.Получить();
СписокУзлов = МодульПовторногоИспользования.ПолучитьУзлыОбмена(Идентификатор);

Способ №2: Использование регистров сведений для «быстрого доступа»

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

В таких случаях лучше использовать регистры сведений. Это архитектурно более правильный путь для оперативной передачи данных между сеансами:

• При записи документа или изменении узла обмена, используйте подписку на событие.
• В подписке на событие записывайте актуальный результат в регистр сведений.
• Чтение данных из регистра сведений всегда гарантирует получение актуальной информации без необходимости инвалидации кеша.

Почему это важно?

Рассмотрим причины, по которым не стоит полагаться на стандартные механизмы оповещения в сложных задачах:

Во-первых, система кэширования в 1С призвана минимизировать обращения к базе данных. Попытки принудительно «очистить» кэш из другого сеанса — это борьба против логики работы платформы.

Во-вторых, предложенная нами схема с параметром-идентификатором позволяет системе самой решать, когда выполнять запрос. Это делает код «пуленепробиваемым» в многопользовательской среде.

Рекомендации по реализации

Разберем, какой подход выбрать для вашей задачи:

1. Если условия обмена меняются редко, используйте параметризацию функции модуля повторного использования.
2. Если обновление должно происходить мгновенно при каждой записи объекта, лучше реализовать логику через регистр сведений, который будет выполнять роль кэша, управляемого самим разработчиком.
3. Не забывайте, что функциональные опции также могут выступать в роли триггеров. Изменение значения ФО вызывает инвалидацию всех зависимых от них кэшированных данных во всех рабочих процессах сервера.

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