Какой CacheLookup выбрать? Почему?

[Андрей К.]

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

[Logger]

Разница NotInTTS и Found

[S.Kuskov]

Вот тут хороший пост есть, показывающий разницу между возможными режимами кэширования. Разница NotInTTS и Found
А выбор какого-то определённого режима я думаю напрямую должен зависит от степени распределённости и интенсивности изменения/чтения данных в таблице.

UPD.: Со ссылкой уже опередили

[Logger]

Только еще нужно помнить что он написан для 3-ки
Возможно для 2009-й будут отличия. - я их не проверял.

[Vadik]

Цитата:

Сообщение от Андрей К.

Ни в одной документации не нашел четких рекомендаций
..
я не нашел никакой информации от MS

Let me Google that for you

[Андрей К.]

все это я уже читал.
тем не менее хотелось бы уточнить:
если в кеш попал результат запроса
SELECT * FROM InventLocation A WHERE INVENTLOCATIONID='Нет склада'
а затем кто-то изменяет данную строку, то при очередном селекте я не получу актуальные данные?

[Андрей К.]

Цитата:

Сообщение от S.Kuskov

А выбор какого-то определённого режима я думаю напрямую должен зависит от степени распределённости и интенсивности изменения/чтения данных в таблице.

вот именно об этом и хотелось поговорить.
степень распределенности - это грубо говоря какой процент от всех записей наиболее часто используется?

вопрос в лоб: у каких таблиц кэширование стоит вырубить? и почему?

[S.Kuskov]

Цитата:

Сообщение от Андрей К.

если в кеш попал результат запроса
SELECT * FROM InventLocation A WHERE INVENTLOCATIONID='Нет склада'
а затем кто-то изменяет данную строку, то при очередном селекте я не получу актуальные данные?

Так точно

Цитата:

Сообщение от Андрей К.

степень распределенности - это грубо говоря какой процент от всех записей наиболее часто используется?

Я под этим имел ввиду вероятность чтения/изменения данных одновременно несколькими клиентами. Т.е. на сколько эта вероятность высока или низка.

Цитата:

Сообщение от Андрей К.

вопрос в лоб: у каких таблиц кэширование стоит вырубить? и почему?

Ну, например, для таблицы InventSum (Остатки в наличии), с моей точки зрения, жёсткое кэширование записей противопоказано. Т.к. её значения с большой вероятностью могут быть изменены процесами других конкурентных пользователей. А например для таблицы UserInfo (Параметры пользователя) кэширование можно включить относительно безопасно. Наверное замечали что после изменения параметров пользователя они применялись только после перезапуска клиентской сессии? Если вас такое поведение устраивает то кэширование можно оставить

[AndyD]

Цитата:

Сообщение от Андрей К.

все это я уже читал.
тем не менее хотелось бы уточнить:
если в кеш попал результат запроса
SELECT * FROM InventLocation A WHERE INVENTLOCATIONID='Нет склада'
а затем кто-то изменяет данную строку, то при очередном селекте я не получу актуальные данные?

Зависит от многих факторов.

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

Во-вторых, какой тип кэширования выбран и используется ли транзакция во время выборки - для notInTTS используется разный кэш внутри и вне транзакции

В-третьих, сколько времени прошло со времени попадания записи в кэш - в 24 часа кэш сбрасывается (есть параметр, позволяющий уменьшить период, но на 2009-й у меня не заработало, а на 3.0 - не пробовал)