Внезапно вспомнил одну старую проблему и решил спросить.
1С УТ 11. Конкретную версию платформы и конфигурации не помню, потому что это было достаточно давно. Работали несколько удаленных магазинов, в одной общей базе.
Выполнялся запрос к документу.
Запрос простейший, буквально вида

ВЫБРАТЬ
   докТовары.Номенклатура
ИЗ
   Документ.КрасныеЦены.Товары КАК докТовары
ГДЕ
   докТовары.Ссылка.Проведен
   и докТовары.Номенклатура В (&массивНоменклатуры)

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

Суть в том, что большую часть времени все работало правильно. НО, иногда, запрос работал некорректно. К примеру, в документ красных цен добавили новую номенклатуру, записали, провели. А в магазине этого не видят - строчка с этим товаром не выделяется цветом, скидка с нее не сбрасывается. Напомню, работа в одной базе - никаких обменов. Если в этот момент закрыть программу и заново открыть - то сразу же после этого запрос отрабатывает корректно, возвращает все, в т.ч. и новую добавленную номенклатуру.
Или в офисе уберут какой-то товар из документа красных цен - а в магазине он упорно продолжает выделять цветом и сбрасывать скидки. Открываешь у себя - тот же самый товар не выделяется цветом, т.е. все нормально. Перезапустит магазин программу - и у них все нормально становится.
Причем это буквально три-четыре раза проявилось - т.е. в остальных случаях корректно все отрабатывало. Экспериментировали - специально меняли что-то в документе, через секунду проверяли в магазине - изменения корректно отображались. Т.е. в большинстве случаев все корректно, только изредка происходило нечто непонятное, в результате чего запрос возвращал не те данные. Собственно, отловить это именно мне, т.е. чтобы в консоли запустить запрос, проверить - вообще ни разу не удалось. Это только магазинам так "везло".
После перевода документа на проведение в регистр сведений и запрос к регистру проблемы ушли. Больше ни разу ничего подобного не было за почти два года.
Есть большие подозрения на то, что документ кэшировался и данные брались из кэша.
Собственно, так ли это? Такое поведение вообще нормальным было? Я читал про обычный и транзакционный кэш, но никогда с ним не было проблем, кроме этого случая с запросом к документу.
Можно еще какие-то подобные сюрпризы ожидать от 1С? В справочниках, еще где-то? Не знаю, к примеру - изменили название номенклатуры, а в другом запущенном сеансе будет показываться старое, пока 20 минут не пройдут, и обычный кэш не очистится? И можно ли эти кэши чистить, в оперативной памяти?

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

А на файловой версии базы такой глюк не пытались словить?
Напрашивается подозрение, что это эффект от вида СУБД, когда одна версионник, а другая блокировочник

С 99%-ной вероятностью никакого глюка не было. Просто кто-то менял документ КрасныеЦены.
Узнать это можно только, если включено версионирование этого документа.

Либо использование модулей с повторным использованием возвращаемых значений https://its.1c.ru/db/v8std/content/724/hdoc

(1) из общего модуля, где повторное использование возвр. значений "НЕ использовать"
(2) база MS SQL. На файловой не пытались, т.к. он проявлялся редко и непредсказуемо. Наверно, можно было неделю сидеть, тыкаться - и ничего не словить.
(3) Нет, дело не в изменении документа. Как минимум один раз (может и больше, не помню) точно удалось словить такое, что я под своим пользователем захожу - у меня все правильно. Магазин в тот же самый момент (по удаленке зашел к ним и смотрю) - у них некорректная информация. Сам перезапускаю у них программу - и все, волшебным образом у них тоже все правильно.

(4) запрос то в какой момент отрабатывает?

Кеш ?

(4) >> ... и все, волшебным образом у них тоже все правильно.

Животрепещущая история конечно. Но ничего не доказывающая.
Чудес не бывает.
Возможных причин не так уж и много.
1. Кто-то третий всё-таки правил документ КрасныеЦены, пока вы с магазином пытались моделировать глюк.
2. Запрос возвращает правильные данные, а ошибка в коде, отвечающем за раскрашивание номенклатуры или ещё где-то по пути от запроса до отображения информации.
3. Где-то всё таки применяется опция общих модулей с повторным использованием возвращаемых значений. Может не в том самом модуле, где запрос выполняется, а в другом в цепочке стека вызовов.

А вариант "глюк СУБД" я лично рассматривал бы в самую последнюю очередь.

(5) Смотрели на раскрашивании строк. Динамический список в допиленной форме Чека ККМ  ФормаДокументаРМК. Событие ПриПолученииДанныхНаСервере. Оттуда вызов общего модуля, который ничего повторно не возвращает.
(6) Возможно. На него и думал. Но дело до конца не довел, т.к. все решилось другим путем.
(7) Я и не думаю про глюк СУБД (MS SQL Server). Я грешу на какое-нибудь хитрое кэширование 1С, которое такое "О-па! А мы уже недавно обращались к этому объекту, зачем нам его тягать из БД, давайте я вам его из кэша в оперативной памяти отдам".

(8) чет я хз как тут можно притянуть объектный кэш. да и он вроде версию объекта учитывает, так что при изменении перечитается