Кто знает, как обновить объектный кэш по ссылке? Сеанс 1 записал объект. Сеанс 2 получил сигнал, что объект Х записан в другом сеансе. Но объект Х в сеансе 2 может уже находиться в объектном кэше. Нужно гарантировать обновление этого кэша. Как?
Если открываю транзакцию, то всегда получаю актуальный объект. Но если фиксирую транзакцию, то после этого снова используется старый кэш. https://www.hostedredmine.com/issues/948225

Метод Прочитать() объекта всегда считывает актуальные данные. Но опять же не обновляет объектный кэш. https://partners.v8.1c.ru/forum/topic/1383852

(0) Почему я раньше не узнал про этот трекер...

Штатно - никак.
Думаешь для чего в типовых вдоль и поперек используется костыли типа ЗначенияРеквизитовОбъекта()

И вообще, рекомендованный способ чтения данных - запрос

(3) В документации описан способ с транзакцией, но он в реальности не работает https://its.1c.ru/db/pubdevguide83#content:304:hdoc

(2) Наверное потому что ИР не юзаешь.

(5) Я бы не стал полагаться на такой способ. Объектный кэш штука эфемерная. Тем более, на границе сеансов. А если у тебя сеансы на разных рпхостах? А если на разных серверах?

(7) Ну если эту ошибку исправят, то почему это я не должен на него полагаться? Там все про один сеанс написано. Зафиксировал транзакцию - все обновления из нее должны попасть в обычный кэш твоего сеанса.
Кстати у разных сеансов одного рабочего процесса (rphost), судя по моим экспериментам, нет общего объектного кэша. О чем я сообщаю по ссылке в (0).

(8) Ну вот же ты пишешь: "при записи объекта обычный объектный кэш обновляется, но только для того сеанса, который выполнял запись".
Значит ИТС не врёт. Никто вроде не обещал, что объектный кэш будет общим у разных сеансов.

В другом сеансе обновится, если там новую транзакцию начать

А то что общего кэша нет - это всем известный факт (хоть и противоречиь здравому смыслу)

(11) В документации я не нашел освещения этой особенности. Может подскажем ссылку, откуда этот факт общеизвестен?

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

(10) Обновится кэш транзакции, но не обычный кэш. В (0) есть воспроизводимый пример.

(9)  Я не утверждал, что "объектный кэш будет общим у разных сеансов". Да и это мне не требуется, хотя было бы разумно с точки зрения использования памяти.

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

Почему объектный кэш плох на границе сеансов - я написал в (7). Если вы говорите "у нас общий кэш" для сеансов, вам надо обеспечивать консистентность как минимум. Зачем?
Вендору проще написать "ребята, вот вам запросы, вот их и пользуйте, там актуальные данные почти всегда".

(0) Когда второй сеанс обратится к объекту из кеша будет выполнена проверка версии данных в кеше и в БД. Если они отличаются (а если вы записали этот объект в другом сеансе, то они должны отличаться), то второй сеанс обновит объект в кеше.

(18) Ты забыл самое главное - в течение <20 секунд при обращении к обычному объектному кэшу проверка изменения версии данных не выполняется https://its.1c.ru/db/pubdevguide83#content:303:hdoc

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

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

(21) Кто здесь предлагал каждый раз проверять?

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

(23) Где я просил чтобы значение было всегда верным? Для этого существует транзакционная блокировка.
Я задачу довольно четко описал в (0) - гарантировать обновление кэша объекта по сигналу. Не надо выдумывать другие задачи.

(24) судя по документации есть пара способов это сделать одинаковой бессмысленности:
- подождать 20 минут
- вытеснить другими данными

Какой смысл в такой задаче?

v8: Проблема с кэшированием данных формы

(25) Например, документ оплаты, на форму выведен договор (реквизит документа) и через точку реквизит договора "Сумма".
Пользователь 1 меняет сумму, пользователь 2 открывает - сумма старая. Так и будет 20 минут висеть. Можно создать отдельный реквизит на форме и через запрос его заполнять, либо принудительно через оповещение обновить при открытии документа, но там нельзя передать ссылку.