в качестве апа темы Сохранить менеджер временных таблиц между серверными вызовами.

может что-то поменялось в этом плане или камрады таки придумают маневр?

Менеджер в Структуру, структуру во Временноехранилище

(1) один хрен сериализация

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

(3) вариант в принципе рабочий, получается запись параметров нового запроса и в фоновом по быстрому циклу чтение, потом результат запроса - в сообщения фонового. видимо без извращений не обойтись

я как-то давно делал вечный цикл в нескольких фоновых с лонг-поллнигом приблуды на ноде. а управляющее фоновое (и не только) передавало в ноду нужные данные для обработки в очередь. таким макаром можно в этих фоновых и мвт хранить

еще менеджер блокировок 1с юзал так же для блокировки объектов для внешних систем - одно фоновое в нем документобъект.заблокировать/разблокировать

(0) временные таблицы - это объекты субд (temptable) - они создаются и удаляются по командам  
Если ты знаешь имя временной таблицы - попытайся обратится к ней по имени как к обычной таблице sql

(7) там есть 2 типа временых в скл, которые доступны в рамках сессии или в рамках запроса (не помню точно как зовутся), дак вот тут как раз в рамках запроса. т.е. видишь эту таблицу в sql а обратиться к ней никак не дает..

(5) а передавала данные - через запись в базу ли как? точнее даже - откуда получаело управляющее фоновое следующее задание? (у меня это интерактивно от действий пользователя случается)

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

(9) к серверу на nodejs делался запрос, он отправлял его в первый попавшийся висящий на лонгполле клиент.

управляющее фоновое задание анализировало граф зависимостей последовательности документов по измерениям. это многопоточное восстановление было.

(11) если ты путаешь перед с задом то точно не понимаешь как оно должно работать.

(10) гений, это долго

попрбую через висящее фоновое и выдачу ему заданий через запись в регистр сведений

(14) Озвучь задачу

(14) нет делаешь через сеанс у всех фоновых в рамках сеанса ВХ доступно

(16) что ты поместишь в вх? таблицу а потом ее подгружать в запрос?  (поместить туда сам диспетчер временных не выйдет)

(17) 1. "диспетчер временных" - что за выдуманная дичь?
2. Озвучь задачу.
3. гоняешь тз через вх.

(18) 3 - долго,

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

(19) по логике надо эту тяжелую таблицу сохранять в БД
короче вьюхи нужны
в скуле они есть, осталось добавить поддержку в платформу 1С

Можно еще через функцию повторного использования возвращать структуру,а в нее уже класть все,что нужно.

(21) В частности, следует иметь в виду, что кэш не хранит данные вечно. Закэшированное значение будет удалено из кэша через 20 минут после вычисления или через 6 минут после последнего использования (в зависимости от того, что наступит раньше*).
https://its.1c.ru/db/v8std/content/724/hdoc

https://infostart.ru/1c/articles/1217577/
1. НЕ кэшировать менеджер временных таблиц там, где кэш сохраняется между вызовами сервера.
2. Быть осторожным с циклическими ссылками. В принципе, это относится не только к менеджеру ВТ, но и к любой разработке.
3. Вместо кэширования менеджера ВТ подумать над архитектурой. Возможно кэшируемые в ВТ данные требуют особого хранения в базе для быстрого доступа.

Имхо остается только реализация бесконечного фонового
Во временное хранилище и т.д. между серверными вызовами чревато разными глюками

Имхо я бы создал "регистр сведений временных таблиц" в базе
С максимально универсальной структурой, множество полей разных нужных типов
И писал данные туда понятно с привязкой к измерению-сеансу (уид как пример), чтобы потом как не надо очищать
Ну и соответствие имен полей РС ВТ и моих ВТ

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

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