Показать сообщение отдельно
Старый 22.10.2014, 06:50   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Видимо этот механизм не до конца был проработан разработчиками Microsoft Dynamics.
Как только разработчик произносит, что другие программисты не до конца проработали некий базовый механизм, который существует уже несколько версий...
...скорее всего, сам разработчик не разобрался.

1. ПРОИЗВОДИТЕЛЬНОСТЬ
ни в коем случае НЕ стоит изменять режим кэширования на продакте.

Конечно, попробуйте на тестовой базе. И убедитесь, что отключение кэширования таблицы PriceDiscTable немедленно приводит к DDOS'у SQL сервера мелкими запросами по этой таблице.

И это неспроста.
Изначальные разработчики Аксапты не боялись мелких, простых и частых запросов к SQL именно потому, что отлично работал кэш.
Поэтому зачастую лучше написать пару простых запросов в цикле (они будут брать данные из кэша) вместо сложного SQL-запроса с join.

2. ПРОБЛЕМА ПО СУТИ
Сама постановка проблемы является надуманной.
Дело в том, что кэш так или иначе обновится максимум через 15 минут.

В многопользовательской системе 15 минут обычно не влияют на работу пользователей. Пользователь1 обновил цены, в течение 15 минут у Пользователя2 цены гарантировано будут обновлены. Если в течение этих 15 минут у Пользователя2 будут задействованы старые цены - обычно ничего критичного не происходит. Это нормально.

15 минут становятся проблемой, когда появляется 1 (один) тестер и гоняет бизнес-процессы. Тогда да, наличие кэша и период до 15 минут становятся проблемой. Но это проблема тестирования, а не реальных бизнес-процессов. В тестировании перед каждым новым бизнес-процессом надо тупо сбрасывать кэши командой "Tools \ Caches \ Refresh data".
За это сообщение автора поблагодарили: AlexeyS (1), gl00mie (3).