Вопрос следующий. В коде программы нужно периодически обращаться к реквизитам документа. Это можно делать через объект, а можно через ссылку. Правильно я понимаю, что если обращаться через ссылку, то при каждом обращении к реквизиту выполняется запрос к БД, а если через объект, то реквизиты считываются из оперативной памяти, куда они были записаны при считывании объекта? Как в этом контексте грамотнее организовать работу с объектами 1С, через ссылку или через объект?

Через ОбщегоНазначения.ПолучитьРеквизитыОбъекта(), разумеется

вроде ещё не пятница.

(0) Объект у тебя откуда берётся?

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

Ссылка - это только ссылка, объект - это документ целиком.
При обращении к реквизиту ссылки подгружается объект целиком, если он еще не был подгружен. При втором обращении к другому реквизиту запроса к БД не будет
Если нужна скорость, то (1)

(5) "При втором обращении к другому реквизиту запроса к БД не будет"

Зависит от интервала обращения ))

(4)  1С:Предприятие 8.3. Практическое пособие разработчика, Занятие 14 (3:20) Оптимизация проведения документа «Оказание услуги», Теория: устройство кеша

(0) А можно получить значения нужных реквизитов через запрос. Вроде так быстрее всего, т.к. получаешь не все подряд а только нужное.

Читай про объектный кеш https://its.1c.ru/db/pubdevguide83/content/285/hdoc/_top/объектный%20кеш
можно сразу с конца статьи

(8) Не всегда. Если объект уже есть в объектном кеше, то выгоднее его взять оттуда.

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

(6) то есть если получать реквизиты через ссылку - то получаем при потоврном обращении к другому реквизиту по ссылке спустя короткое время - устаревшее значение? или при оьращении по ссылке проверяется "акутальность" ссылки?

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

(4) Если у тебя уже есть объект, то однозначно использовать объект. А если ты хочешь сначала получить объект, то лучше (1)

(12) Не устаревшее. А новое обращение в БД.

(15) ну ты ж сам пишешь в (6) - "другого обращения к БД не будет"
..?

(16) если кто-то обновил реквизит - значит другое обращение к БД уже было

(17) а откуда мой сеанс знает что кто-то в другом сеансе обновил реквизит у объекта?

(16) кэш обновляется при записи объекта в любом сеансе, каждый раз проверять валидно6 смысла нет

При работе с реквизитами объекта не происходит обращение к бд, но данные могут быть неактуальными.

мнения расходятся )

(19) а откуда кэш обьекта знает что ему обновиться надо: или при обновлении обьекта в одном из сеансов - база(сервер) пушем ПО ВСЕМ СЕАНСАМ где есть кэщ этого объекта производит принудительное обновление этого кеша? как это вообще работает?

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

Ну вот Вы изменили реквизит объекта но не записали объект. Считываете - получаете изменённое значение. Значит данные из памяти.
P.s. Так можно проверить был ли изменён реквизит - сравнить Объект.МойРеквизит с результатом запроса.

В итоге - нихрена не понятно.

(22) сервер не дурак - он знает о всех своих сеансах

(25) https://its.1c.ru/db/pubdevguide83#content:303:hdoc

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

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

Если окажется, что версии данных не совпадают (т. е. произошло изменение данных в базе данных), данные, находящиеся в кеше, будут удалены из него, и будет выполнено повторное считывание данных из базы данных. Начиная с этого момента, идет отсчет следующего 20-секундного интервала валидности этих данных.

Кроме всех вышеперечисленных событий считанные данные будут удалены из кеша по истечении 20 минут после их последнего считывания из базы данных.

(27) в итоге, если в 20-секундном интервале какая-то другая сессия изменит данные в базе, то я в моей сессии в рамках этого 20-и секундного интервала получу невалидные данные по объекту, так?

Ну и вообще откуда данные что у каждого сеанса свой кэш

(28) ты просто пытаешься смоделировать работу кэша на языке 1с. Но этого конечно не получится

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

(29) в (28) не ставится вопрос о разные или не разные кэши.

(29) в (28) простой тупой вопрос.

(32) в чем проблема при записи объекта сказать серверу чтоб он удалил его из кэша (всех кэшоов если их много)

Ну а на твой вопрос: в кэше всегда последняя версия

(34) я ничего не записываю.

(28) да, всё верно ¯\_(ツ)_/¯

(35) нестыкоывка.
"Если интервал превысил 20 секунд, будет выполняться проверка на соответствие версии данных, хранящихся в кеше, версии данных, находящихся в базе данных."
- если в кеше всегда последняя актуальная версия - зачем "будет выполняться проверка.."..?

(28) если оперируем ДокументОбъект, то нужно ставить блокировку и тогда никто не сможет изменить документ во время выполнения нашей операции. А если не сможем ее установить, то и обрабатывать смысла нет, т.к. при записи получим ошибку.

(37 нестыковка с (35)

Да получается я не верно прочитал, вернее не читал конечно, но думал что в 1с нормальные проги

(40) у меня нет цели стыковать описание механизма работы кэша с мнением всех форумчан)

Сделайте кто-нибудь тест на тему

(42) угу. а то ты из себя некотоые спецов строят.. ;-)
В итоге - если не предпринимать спецдействий - есть шанс получить невалидное значение из кеша.

Вопрос77: я правильно понимаю, что в 8-ке наверное есть возможности получить валидное значение не блокируя объект на изменение, типа перечитав актуальное значение объекта?

(44)>>в 8-ке наверное есть возможности получить валидное значение не блокируя объект на изменение

запрос же))

(45) а без запроса?
если нужен объект целиком а в объкте стотыщ реквизитов - все перечислять в запросе?

(39) Транзакции хватит.
Там два объектных кэша - обычный и транзакционный. В документации по ссылке из (9) все написано.

(46) "*"

(46)

Прочитать (Read)
Синтаксис:

Прочитать()
Описание:

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

Доступность:

Сервер, толстый клиент, внешнее соединение, мобильное приложение(сервер).
Примечание:

Позволяет прочесть данные заново. Недопустим для нового объекта.
Пример:

Объект.Прочитать();

хотя настолько глубоко работу кэша я не копал

(44) > В итоге - если не предпринимать спецдействий - есть шанс получить невалидное значение из кеша.
Только вне транзакции и тогда это обычно несущественно.

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

(52) А что, актуализация объекта (тм) может происходить без запроса к бд?

(53) запрос (обращение к БД) понятно что при аткуализации будет.
получается что в 8-ке актуализировать объект в основном запросом (конструкцией языка) приходится, так?

(0) Объект для записи. Ссылка для чтения. А оптимальнее читать значения реквизитов запросом. P.S. Если не планируешь записывать, а только читать данные не нужно получать объект.

(54) А где это не так?

(52) Где гадость? Если ты не блокируешь прочитанную инфу явно или неявно, то ни в какой момент времени у тебя не может быть уверенности в ее актуальности. Но такая уверенность обычно нужна только в транзакции, а там все Ок. Это справедливо для любых систем.

запись не требуется.
только чтение данных.
см. (5), (6), (12), (15)
.
допустим я через ссылку обращаюсь к одному и тому же реквизиту в моменты времени Т1 и Т2, и между Т1 и Т2 данные в базе изменены (значение реквизита изменено) - в момент времени Т2 - я получу неактуальное значение, устаревшее (если между обращениями менее 20 сек)..? так?

(58) В файловой - вероятно, можешь

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

При этом платформа не даст изменить объект, состояние которого изменилось с момента чтения. То есть надо достаточно извратиться, чтобы нарыть себе в этом месте неудобство.

(60) в 5-6-12-15 - там даже про объектную технику не шло речи. изначально - про работу с реквизитами через ссылку. далее сказано что при дергании реквизита через ссылку - читается весь объект (это объектный кэш? или что?). ну а далее плавно перешло к обсуждению актуальности данных этого _неявно_ считанного по ссылке.реквизиту объекте...

(59) то есть в скульной и файловой базе поведение по выдаче данных - будет разное?

(61) это понятно, здесь вопросов нет.

(63) Не в скульной, а в серверной.

(60) "Такие обработки обычно не совмещают с активным изменением данных."
а не надо изменять данные. достаточно того, что на основании неактуального значения будет принято неверное "решение"

(65) согласен с уточнением.

(58) нет.
Если в коде написано Ссылка.Контрагент ты получишь контрагента1. Потом через секунду контрагент изменился на контрагента2. Еще через секунду прочитать Ссылка.Контрагент ты получишь нового контрагента2. Если каждый раз обращаться именно к базе данных всегда будешь получать актуальные значения. Запусти два сеанса. В одном читай построчно отладчиком, а во втором интерактивно меняй значения. Вот и посмотришь

(68) "Если в коде написано Ссылка.Контрагент ты получишь контрагента1. Потом через секунду контрагент изменился на контрагента2. Еще через секунду прочитать Ссылка.Контрагент ты получишь нового контрагента2."
- то есть здесь никакого кэша не используется (правило 20 сек не работает), и "я" получаю всегда актуальные данные? - так?

(62) Ты о чем говоришь? О том, что при активном использовании объектного кэша увеличивается вероятность попасть вне транзакции на рассогласование прочитанных данных? Да.
Но никакого ужаса тут нет. Вполне понятный и оправданный трейдофф.

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

(70) угу. и это понятно.

(70) а по (69)..? из сказанного в (68) следует что при использовании Ссылка.Реквизит - я всегда получаю  актуальные данные, то есть кэш здесь не работает. в (68) правильно изложено?

(71) + Ну или не кэшировать объект при первом обращении через точку, а фигачить точечный запрос.
Вот это вот полное кэширование объекта при первом обращении через точку - пипец неявная засада производительности.
(73) Не. В (68) неправильно.

(74) "в (68) неправильно".
.
я в ахуе.
.
специалисты по 80ке, блин.
.
(68) - говорит что правильно, (74) что неправильно.
.
есть тут еще специалисты? или так, галкорасставлятели только?

(75) Хотя... Надо протестить. Что-то мне не верится, что в УФ в клиент-серверной для каждой сессии заводится отдельный кэш. Как-то это глупо. А единый кэш вообще не проблема при записи сбрасывать.
Да, вот такие специалисты собрались :)

(76) есть и кэш сессии и общий кэш конфы/базы

ну так правильно в (68) или нет...?
специалисты-погромисты...

(77) А зачем в случае клиент-сервера и УФ? Это же кэши одинакового уровня будут.

(78) нет (58) не так

(78) Это только семерочникам критично. Спецам по восьмерке использовать объектный кэш - моветон :)

(79) специфические области видимости
если объект доступен только конкретной сессии нет смысла класть его в общий кэш да еще с привязкой к конкретной сессии чтобы разделять доступ/имя

(80) это как?
ты говоришь, что в (68) - изложено неверно.
при этом ты говоришь что "(58) не так" - то есть _отрицаешь_ вопрос что я получу неактуальное значение.
вообще ничего не понял тогда

(82) Логично. И тогда при записи поиск в сессионных кэшах не делается из соображений производительности, так что ли?

При чем здесь восьмерка или семерка? Поведение одинаковое будет при обращении через точку и в семерке, и в восьмерке. Каждое обращение через точку это новый запрос к базе данных, а не чтение кэша. Нет разницы через 20 секунд , раньше или позже.

Мнения разделились.
неквалифицирован либо Никулин Леонид либо Garykom ибо утверждают противоположное.

(84) + Отвечу сам себе. Наверное, так. Ведь сессии могут быть разбросаны по разным серверам.

(1) >Через ОбщегоНазначения.ПолучитьРеквизитыОбъекта(), разумеется
Доколе. Когда уже сделают встроенную функцию.

(86) Там вверху была ссылка на ЖКК, которой Никулин противоречит. Изложенное в ЖКК по итогу звучит логично. А проверять лень даже тебе.

(86) прочитай внимательно (58)
а затем слово "нет" в (68) и (80)

(89) мы совсем на другой вопрос отвечали

(91) Если твой ответ на (58) "нет" верен, то для этого должна происходить синхронизация всех сессионных кэшей при записи.

В части инфы по записываемому объекту

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

(85) "Поведение одинаковое будет при обращении через точку и в семерке, и в восьмерке. Каждое обращение через точку это новый запрос к базе данных, "
- в части 77 - утверждение неверное.
СпрН.Производитель и СпрН.ТекущийЭлемент().Производитель - дадут разные значения.

(94) а если механизм не сработал будут разные прикольные глюки как часто довольно бывает
когда рекомендация почистить кэш помогает

(89) я проверить не могу. я по 8-ке только юзер, а не прог.
поэтому - как тест - вот я юзер. и кому мне верить..?
тут блин все спецы восьмерочные...  такие.. спецы...

(95) ты не путай разные значения до записи в базу, когда одно уже поменяли

(94) То есть по ссылке в (9) чушь собачья?
"При повторном обращении к кешу за данными уже считанного объекта будет анализироваться интервал времени, прошедший с момента появления данных в кеше.
Если обращение происходит в пределах 20 секунд после поступления данных в кеш, данные считаются верными (валидными). Если интервал превысил 20 секунд, будет выполняться проверка на соответствие версии данных, хранящихся в кеше, версии данных, находящихся в базе данных"

(98) это мы обсудим позже. так как малость в сторону от основнйо темы по 8-ке

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

Возвращаемся к истокам ибо непонятно (убежали в обсуждение разных кешей и прочего).
.
написанное в (68) - что при обращении ссылка.Реквизит - всегда будет актуальное занчение
- верно или неверно?

(95) Конечно могут дать разные значения. (кстати и в 7-ке и в 8-ке). СпрН.Производитель - это ты из базы читаешь. СпрН.ТекущийЭлемент().Производитель - а это с формы :)

(99) >То есть по ссылке в (9) чушь собачья?

по ссылке (9) у меня нет никакого текста про 20 секунд

Да, и непонятно твое "фу какая гадость". Так работает любой кэш в принципе.

(101) в 68 про запрос как термин языка программрования речи не идет.
речь только о получении значения через
Ссылка.Реквизит

(102) Неверно

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

(103) нет. это не с формы. это тоже из базы.
форма. на форме - поле выбора ВыбНоменклатура и три кнопки\
Сформировать. Сформироват1 и Сформировать2
.
Перем СпрН;

//*******************************************
Процедура Сформировать()
    
    СпрН = СоздатьОбъект("Справочник.Номенклатура");
    СпрН.НайтиЭлемент(ВыбНоменклатура);
    
КонецПроцедуры

//*******************************************
Процедура Сформировать1()
    
    Сообщить("СпрН.дПроизводитель = "+СпрН.дПроизводитель);
    
КонецПроцедуры

//*******************************************
Процедура Сформировать2()
    
    Сообщить("СпрН.ТекущийЭлемент().дПроизводитель = "+СпрН.ТекущийЭлемент().дПроизводитель);
    
КонецПроцедуры

(108) да нашел ссылка
https://its.1c.ru/db/pubdevguide83#content:303:hdoc

Никулин Леонид, вам говорят что вы в (68) - лажаете, то бишь не знаете основ...
что ответите?

(106) Выражение Ссылка.Реквизит может быть и в коде, и в запросе.

(95) Конечно могут дать разные значения при таком синтаксисе. Кстати как в семерке, так и в восьмерке. прН.Производитель - это ты из базы данных читаешь. А СпрН.ТекущийЭлемент().Производитель - это с формы :)

(110) Похоже на правду, потому что для файловой и ОФ - задолбаешься сессионные кэши обновлять. Они ж на клиенте должны быть. А для УФ сессии могут на разных серверах находиться и тоже встанет в копеечку.

(112) запрос не рассматриваем.
речь про использование Ссылка.реквизит в коде

(111) Только ты это говоришь.

(113) еще раз: СпрН.ТекущийЭлемент().Производитель - это не с формы.

(116) хорошо.
уточняем.
.
если читать (68) и считать что Ссылка.Реквизит используется в коде, а не в запросе - написанное в (68) - верно?

(114) 1С при записи объекта сначала его всегда читает (будет попытка из кэша)
Так что расхождение получить очень сложно
20 секунд это вероятно правила на случай сбоев чтения/записи

Но в случае двух и более серверов 1С на одну sql базу это мдя

(118) Уже разъяснили не раз. В коде Ссылка.Реквизит получишь значение из кэша. Может оказаться неактуальным.

(119) Да нет. 20 секунд - это ключевое правило протухания кэша. Иначе кэш вообще теряет смысл. Проверить версию - дорого. Обновлять все кэши при записи - тоже дорого.

(120) механизм блокировок тут еще работает

(121) тогда какой смысл держать данные в кэше 20 минут или до вытеснения?

(121) + Вероятно, для УФ и клиент-сервера можно было бы заморочиться с оптимизацией актуализации кэша. Но большого смысла это не имеет.
(123) Неточно выразился. 20 секунд - это период не протухания, а проверки актуальности. А протухание - 20 минут.

(124) с учетом "Проверить версию - дорого. Обновлять все кэши при записи - тоже дорого"
откуда взялись эти 20 секунд? почему не 10 или не 30?

(113) на, играйся https://dropmefiles.com/MTAk2 - на форме вообще нет никаких пеквизитов оносящихся к данным базы.
1. скачать обработку.
2. типовая тис
3. открыть обработку
4. нажать Сформировать, выбрать элемент справочника (запомнить какой)
5. нажать Сформировать1 и Сформировать2 - названия одинаковые
6. открыть форму элемента справочника выбранного в п.4. изменить название. записать, закрыть форму элемента.
7. нажать Сформировать1 и Сформировать2 - названия разные.
.
наименование, полученное через точку в разные моменты времени - не актуальное!
для получения актуального значения реквизита через точку это надо указывать явным образом.
.
Никулин Леонид вычеркивается из списка клюшечников.

(120) ответ получен.
значит Никулин Леонид в (68) написал лажу.

(127) Если бы мне это было интересно настолько же, насколько тебе - я бы проверил на практике. Потому как мало ли. Это внутренние механизмы, а они могли или поменяться или в ЖКК могли лажануть.

(124) протухание - это значит значение из кэша "убивается", его там нет?

(128) так.. еще один спец, который не знает... так и рождаются типа как у фузины 2+2=5. бо одно слагаемой неактуальное стало...

(127) лень ставить 77 но думаю у тебя разные объекты в (126)

(131) здесь объект - элемент справочника.
один и тот же.

(131) кода там - гулькин лилипут...
Перем СпрН;

//*******************************************
Процедура Сформировать()
    
    СпрН = СоздатьОбъект("Справочник.Номенклатура");
    Пока СпрН.Выбрать("Выбери любой элемент справочника номенклатуры",) = 0 Цикл КонецЦикла;
    
КонецПроцедуры

//*******************************************
Процедура Сформировать1()
    
    Сообщить("(из <кэша>) СпрН.Наименование = "+СпрН.Наименование);
    
КонецПроцедуры

//*******************************************
Процедура Сформировать2()
    
    Сообщить("(из базы) СпрН.ТекущийЭлемент().Наименование  = "+СпрН.ТекущийЭлемент().Наименование );
    
КонецПроцедуры

(132) хехе
не один
ты в переменную взял а затем напрямую в базе поменял

ты не путай переменная и кэш это две большие разницы

Интересно в 77 насколько аналогична 8-ке
В плане ТекущийЭлемент() и Ссылка

Ещё больше запутаю народ :)) у общих модулей есть свойство "Повторное использование возвращаемых значений" - возвращаемые значения функций кэшируются и удаляются из кэша "через 20 минут после вычисления или через 6 минут после последнего использования"
Источник: "Использование модулей с повторным использованием возвращаемых значений" - https://its.1c.ru/db/v8std/content/724/hdoc

(134) ну да. Именно так.
Никулин говорит, что и в 77
использование Ссылка.Реквизит - дает актуальное значение.
я показываю - что это не так.

(135) это не совсем одно и то же.
это лучше может hogik объяснить.

(136) А это повторное в случае разных сеансов разное?

если Никулин продемонстрирует в 77 то что подтверждает его слова - буду исследовать.

(137) Ха
В 8-ке есть
Ссылка.Ссылка.Реквизит!

(141)+ Смотри у тебя в 77
СпрН.Наименование
и
СпрН.ТекущийЭлемент().Наименование

В 8-ке
СпрН.Наименование
и
СпрН.Ссылка.Наименование

(139) Слушай. А откуда ты вообще взял инфу про сессионные кэши? Или это твои догадки? Я нигде ничего подобного не видел. Везде речь как про общий серверный кэш.

(143) Догадки
Подозреваю что кэш один но разделен на общий и сессионные
Причем объекты могут мигрировать

(144) Тогда вряд ли. Овчинка выделки не стоит. Заглянул кстати в проф-разработку - там тоже про двадцатисекундный интервал валидности. Скорее всего Радченко оттуда и утянул.

Но писалось это еще для 8.0
Поэтому мало ли...

(145) «Серверный» кэш или » или как его еще называют – «сеансовые данные на сервере»

(147) http://www.gilev.ru/snccntx/

(142) в 77 такого реквизита как "ссылка" впрямую недоступно.
.
СпрН.ТекущийЭлемент().Наименование - это актуальное значение, дергается из базы.
если так не нуказать, а прсото реквизит через ссылку - то в общем случае будет неактальное значение реквизита.
для актуальносьти - надо принудительно дергать базу , в 77 это СпрН.ТекущийЭлемент().Реквизит.
в (68) то же самое (для 8-ки, без текущийэлемент()) утверждается что Ссылка.Реквизит - каждый раз дергает базу, вроде как большинство сошлось на том, что это не так...

(147) Ересь. В ЖКК сеансовые данные нигде не называют "серверным кэшем". Только на форумах, когда ищут чего бы где почистить.

Короче, склифасовские восьмерочники ;-)
я пошел жену к метро встречать, миозги проветрить, а вы как-то определите стопудово 100% в (68) лажа или нет. а то нехорошо как-то.. человек программирует веря в другое...

(150) находится где? на сервере!
суть кэша? кэша!
= "серверный кэш" :)

И уж совершенно точно сеансовые данные не имеют никакого отношения к кэшу представлений и объектов.

(149) в 77 ТекущийЭлемент() в 8-ке Ссылка

(149) В 8-ке "принудительно дергать базу" это запрос. Или, для удобства, ОбщегоНазначения.ПолучитьРеквизитыОбъекта().

(147) Эээ... Сеансовый кэш хранится по умолчанию в файлах C:\Program Files\1cv8\srvinfo\reg_1541\snccntx + уникальный идентификатор- туда сбрасывается всё то, что получается при серверных вызовах. Т.е сеансовые данные вторичны по отношению к серверным кэшам. Вот как-то вот так.

(156) кэш второго уровня?

(154) нееее! в 77 ТекущийЭлемент() это не то что ссылка в 8-ке, в 77 зависит от контектса использования, например

Товар = СпрН.ТекущийЭлемент();
в "товар" будет не совсем ссылка...
это hogik лучшне объяснил бы. я не полностью копенгаген в этом.

(151) О боже. Да всем насрать. Вопрос чисто академический.

(158)
СпрН.ВыбратьЭлементы();
Пока СпрН.ПолучитьЭлемент()=1 Цикл
   Сообщить(СпрН.ТекущийЭлемент().Наименование);
КонецЦикла;

Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
    Сообщить(Выборка.Ссылка.Наименование);
КонецЦикла;

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

(157) Не совсем так, в 1С всё гораздо запутаннее как всегда. За сеансовые данные "отвечает" менеджер кластера. В кластере могут быть несколько серверов. Если не заданы требования назначения функциональности, то сеансовые данные менеджер распределяет по всем рабочим серверам. Я даже затрудняюсь с определением какого уровня в таком случае эти кэши :(

(162) платформу в 1С тоже запутали как и конфы
логично что тормозит и глючит

(160) это что? типа инфо о схожих вариантах получения данных?
.
в контектсе приведенного кода - ненужное излишество, для 77 достаточно
.
СпрН.ВыбратьЭлементы();
Пока СпрН.ПолучитьЭлемент()=1 Цикл
   Сообщить(СпрН.Наименование); // ТекущийЭлемент() - убрано!
КонецЦикла;
.
результат выполнения совершенно одинаковый
.
а в 8-ке
Выборка.Наименование - не прокатит?

короче - восьмерочники типичные шаманы/жрецы карго... ;-)

(164) >Выборка.Наименование

прокатит

(164) >результат выполнения совершенно одинаковый

ты только что доказал в (126) и (133) что результат разный
в 8-ке аналогично же

(167): вообще-то одинаковый.
полученный из спозиционированного объекта - такой же как (прямщяс) полученный по ссылке на спозционированный объект.

(168) речь про 77

(169)+ и хрень с объектом, в котором изменили но еще не записали в базу
или наоборот объект получили, нечего не меняли а в базе уже поменяно

(169): именно.
(170): "не записали в базу" = "не изменили", и "хрень" - это полагать иначе.

(171) эээ если обращаться к объекту там же уже новые/другие значения отличные от в базе (по Ссылке)

ЗЫ: изменение в сеансе - не изменение в базе.

(173) я это понимаю

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

(174): не понимаешь. т.к. говоришь "в другом сеансе поменяли" имея ввиду данные.

(175) хренакс

смотри ты получил объект из базы (неважно 77 или 8)
я снаружи 1С лезу и меняю напрямую в dbf, 1cd или sql

и?

это тупое обяснение

(167) "ты только что доказал в (126) и (133) что результат разный"
нет.
ранее показано что если получать в 77 реквизит из "ссылки, типа "ссылка.Реквизит" - то нельзя получить актуальное значение после изменения реквизита в базе.
.
в твоем примере - где я указал что ТекущийЭлемент() лишнее -
Пока СпрН.ПолучитьЭлемент()=1 Цикл
   Сообщить(СпрН.Наименование);//
.
актуализация собственно происходит в момент СпрН.ПолучитьЭлемент()
.
!!! конечно, если считаем что в приведенном коде промежуток времени между исполнением оператора СпрН.ПолучитьЭлемент() и оператором Сообщить() для наших целей существенен - то да, за это время может произойти изменение и результат Сообщить будет неактуальный.

(177) Тут сразу получил из базы и используем, да малый промежуток
Но у тебя в твоем примере в переменную записано и использовано потом после нажатия кнопки

Про это речь и веду
Объект.Ссылка.Реквизит - всегда в 1С 8 актуально
Как и в 7-ке ТекущийЭлемент().Реквизит ибо дергается из базы
Но в 8-ке есть еще кэширование на сервере и теоретически может протухнуть

Короче это важно если без блокировок хреначим в многопотоке фоновыми

(178) в моем примере:
нажать Сформироват1 СпрН.Наименование; // ааа
нажать Сформироват2 СпрН.текущийэлемент().Наименование; //ааа
меняем в базе ааа->ббб
нажать Сформироват1 СпрН.Наименование; // ааа
нажать Сформироват2 СпрН.текущийэлемент().Наименование; // ббб
.
просто иллюстрация того, что в (85) в части 77 утверждение
"Поведение одинаковое будет при обращении через точку и в семерке.... Каждое обращение через точку это новый запрос к базе данных"
- неверное.
в 77 обращение к реквизиту через точку в общем случае не есть "новый запрос к базе". а тянет из "кэша".

(178) "Объект.Ссылка.Реквизит - всегда в 1С 8 актуально"
я не спец. так может и всегда актуально
.
а если у нас обьекта нет, а есть только ссылка
то Ссылка.Реквизит в Т1 - тут промежуток где меняем в базе в другом сеансе - Ссылка.Реквизит в Т2 в 8-ке не дает актуального значения.- ВРОДЕ НА ЭТОМ ОСТАНОВИЛИСЬ (в противоположность утвеждения в (85) что дает актуальное).

(179) думать надо очень сильно чтобы писать правильно... а то будет потом 2+2=5

(182) смотри если у нас фибоначчева система счисления ну помним же 0,1,1,2,3,5,8,... или в простых числах 0,1,2,3,5,7,... то
2+2=5 в простых
и 2+2=8 в фибоначчевых ))

// прошу прощения. отличается.
// на морде реквизит ВыбТмц тима Справочник.ТМЦ и формулой "СпрТмц.НайтиЭлемент(ВыбТмц)"
// и кнопка "ТЫЦ" в формулой "Выполнить()"
// модуль формы:
Перем СпрТмц;
Процедура Выполнить()
    Сообщить("СпрТмц.Наименование = """+СпрТмц.Наименование
    +""" / СпрТмц.ТекущийЭлемент().Наименование) = """+СпрТмц.ТекущийЭлемент().Наименование
    +""" >>> "+?(СпрТмц.Наименование<>СпрТмц.ТекущийЭлемент().Наименование,"НЕ ","")+"совпадает","");
КонецПроцедуры //Выполнить
СпрТмц = СоздатьОбъект("Справочник.ТМЦ");
// 1. выбираем в реквизит ТМЦ с наименованием "Тест" (в процессе выбора - открывая его на редактирование)
//    ТЫЦ :  "... >>> совпадает"
// 2. в открытой ранее форме этого элемента меняем его наименование и сохраняем...
//    ТЫЦ :  "... >>> НЕ совпадает"
// извините. был неправ.

ЗВ: в ТекущийЭлемент() - верное, в объекте - кэшированное.

(185) Угу в 8-ке тоже самое, в Ссылка верное, в объекте кэшированное
Но с учетом кэша на сервере 1С и хз как он точно работает может и в Ссылке быть кэшированное

(184) остаешься в списках вменяемых... ;-)

(186) то есть до сих пор непонятно - в (85) верно написано или неверно?

я не восьмерочник, мне проверить трудно в 8-ке сценарий как в 77 в (126)

(186) Что еще за "кэшированное" в объекте?

(190) это я термин из (185) использовал в первой строке (186)
понятно что это нифига не кэш а считанный объект из базы в оперативку

(188) А хрен его знает

Например обращаемся через точку или даже две
Т.е. у объекта есть реквизит ссылочного типа и
СпрН.ВидНоменклатуры.Наименование - может вызвать как запрос к базе так и чтение их кэша ВидНоменклатуры если оно там уже есть

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

(192) Откуда такой вывод?

(193) что и странно.
как бы восьмерке не 2 года, а внятно спецы не могут сказать...

(194) Потому что это внутри платформенный, внутри серверный механизма
Хз дергает ли оно БД или из кэша, про кэш на ИТС есть значит обращения к БД может и не быть
Но рекомендуют использовать запросы, понятно дело результат запроса он слегка устаревший относительно БД, если не заблокировать на запись

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

В параметрах запуска clearcache делает старт 1с немного медленнее. А так да, грустно-скучно.

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

Ну и,протухание объекта проверяется по версии,то есть сначала идет запрос только одного поля версии,а потом всего объекта,поэтому,в некоторых случаях,кеш будет явно не быстрее,а наоборот,сильно медленнее.

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

(47)Транзакции не хватит.
(198)"Но,внутри транзакции,кеш отключается" - вот пример - не отключается:

&НаСервере
Процедура Команда1НаСервере()
    // Вставить содержимое обработчика.
    начатьТранзАкцию();
    эл=справочники.п1.НайтиПоКоду("000000001").ПолучитьОбъект();
    сообщить(эл.Наименование);
      //в это время в другой сессии меняем
      Секунд=10;        
      КомандаWindows = "Timeout /T " + Строка(Секунд) + " /NoBreak";
      ЗапуститьПриложение(КомандаWindows,,Истина);
    сообщить(эл.Наименование);
    зафиксироватьТранзакцию();
КонецПроцедуры

&НаКлиенте
Процедура Команда1(Команда)
    Команда1НаСервере();
КонецПроцедуры

выводит 2 одинаковых наименования.Хотя между 1 и 2 сообщить дает изменить объект в другом сеансе.

(199) Ты вообще не то тестируешь. Ты получил объект и сам держишь его в своей памяти - ессно он менятся из другого сеанса не будет. Должно быть что-то вроде

Ссылка = Справочники.п1.НайтиПоКоду("000000001")
Сообщить(Ссылка.Наименование)

убрал .ПолучитьОбъект() - тоже самое.

(201) Одна из черепашек.
Ради интереса запустил на 8.3.19.1150:

    Ссылка = Справочники.Точки.НайтиПоНаименованию("ФастФуд");

    НачатьТранзакцию();
    
    Сообщить(Ссылка.Наименование);
    ЗапуститьПриложение("Timeout /T 30 /NoBreak", , Истина);
    Сообщить(Ссылка.Наименование);
    
    ОтменитьТранзакцию();

И вторая сессия, изменяющая наименование, честно зависла на записи. Дождалась завершения транзакции и внесла свои изменения. При этом первая, естественно, выдала одно и то же наименование за два обращения.

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


Вторая

сессия - ручное редактирование справочника

Продолжаю наблюдения...

скопировал твой код. У меня он вызывается из формы отчета. Также во второй сессии дает изменять. При этом выводит два разных наименования.  8.3.18.1334

Да, забавно)

По-моему, вот такого допущения должно быть достаточно:
При обращении через ссылку подгружается объект целиком. Это значит, что ближайшее 20 секунд он может быть не перечитан при изменении в другом сеанса или еще где.

(206) Какие еще допущения? Ссылки на RTFM приводили еще в самом начале и походу оно так и работает.

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

Да. В транзакции просто создается свой объектный кэш. А на время ее работы основной объектный кэш просто не используется (не очищается).