Сейчас может напишу бред. Но так выходит. Прошу разъяснить кто в состоянии.
Всегда думал что фоновые задания стартуют с кодом конфы сервера.
Но в реале проделал такой эксперимент.
Открываю 1с в пользовательском режиме. Нажимаю кнопочку на форме. Под ней создание фонового задания. Ожидаю результат "1". Получаю его.
Изменяю конфигурацию. Так чтоб пришёл результат "2". Но при этом я не вышел из старого пользовательского сеанса. Динамически обновил.
Снова жму кнопочку на форме. Ожидаю результат "2". Но снова получаю "1". Т.е. фоновое задание стартовало не с конфигурации сервера, а с моего кэша.
Что реально фоновое задание стартует с моего кэша, а не с сервера?

При динамическом обновлении все сеансы, которые уже открыты, используют прошлый вариант кода, пока не завершаться.

Фоновое задание является чисто сеансовым объектом, но не принадлежит какому-либо пользовательскому сеансу. Для каждого задания создается специальный системный сеанс, выполняющийся от имени того пользователя, который выполнил вызов. Фоновые задания не имеют сохраняемого состояния.

А теперь выйди из старого пользовательского сеанса, зайди еще раз, запусти и удивись.

(2) Но кэш никуда не делся :)

(0) Сервер имеет свой кэш, в чем удивления?

+(0) Запусти фоновое задание при этом с другого ПК и удивись

+ Дополнительно

(0) какая платформа?
у меня был результат 2 при ожидании результата 2

Восьмерочный кэш - зло. Мечтаю, чтобы появился параметр запуска, запрещающий любой кэш на диске.

(9) Запуск без кеша подобно лишению девственности.

(9) К тому же еще и размещен в перемещаемой части профиля. У меня профиль перенаправлен в сеть, классный кеш получается из сети.

(9) Есть такой параметр, называется батник, который перед запуском чистит кеш.

(0) Кеш тут не причем.
Фоновое задание запускается с тем же состоянием (версией динамического обновления) конфигурации, что и родительский сеанс.

(9) (12) пользюки быстренько пойдут жаловаться за это

(14) не пойдут!

(1), (13) интересно а как это реализовано? Передаётся вся конфа на сервер или скомпилированный кусочек (Например только модуль используемый фоновым заданием). Т.е. если фоновое задание вызывает модуль1.метод1, то система на сервер отдаёт этот модуль и информацию о том что надо запустить этот метод. Ведь если вся конфа передаётся как то жёстко для сети. Сейчас фоновые задания запускаются практически нонстопом тормозов нет, отрабатывают за секунду может меньше.

(16) скорее всего, передается просто номер версии метаданных, по которой уже на сервере собирается требуемая конфа из текущей конфы + таблицы дин. обновлений.

(12) И серверный тоже?

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

Динамическое обновление сохраняет версии конфигурации, используемые сеансами - целиком, так как этому сеансу может потребоваться вызов других функций.
Просто, если какая-то версия потом не используется, она должна удаляться.

(17, 20) Спасибо. Буду знать. Интересная вещь

(14) Для этого надо хранить настройки в базе, а не в кэше.

(15) (22) т.е. то, что открытие каждого нового типа документа/отчета будет сильно тормозить, вас нисколько не смущает?