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

(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). Все логично.

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