Проблемы с кэшированием inventSum в DAX2012

[fed]

Коллега показал интересную граблю. Я пока не уверен на 100% что это системная бага, но очень похоже что это так, так что я решил поделиться. Итак: DAX2012 CU3 (без feature pack). Коллега написал маленький дисплейный метод, который тупо выводит для строки заказа незарезервированный остаток. (Не самый лучший способ с точки зрения производительности, но клиент хочет, да и по большому счету проблема не в этом). Демонстрировал мне несколько раз такую картину: По строке заказа ноль. Он запускает развертывание, система создает плановую закупку, он его утверждает и разносит накладную. Возвращается в заказ и рефрешит строку - там по прежнему ноль. Далее коллега идет и синхронизирует inventSum. Заказ показывает правильный остаток. Дальше по заказу разносится отоброчная накладная. Опять - в строке заказа показывает доступное количество (ненулевое). Если опять отсинхронизировать inventSum, количество меняется на правильное - нулевое.
К своему глубокому изумлению, обнаружил что в inventSum стоит кэширование в режиме notInTTS. Причем стоит давно - по крайней мере с версии 2009. Моя гипотеза, почему вся эта ситуация происходит:
1. Как известно, в большинстве случаев, inventSum обновляется через directSQL. (Исключение - ситуации когда транзакция должна обновить всего одну строку в inventSum).
2. Система кэширования AOS не отслеживает обновлений через directSQL, и продолжает хранить в кэше старые данные. Соответственно - чтения данных через inventOnHand или большая часть прямых запросов через inventSum обрабатываются из кэша и возвращают старые данные.
3. В старых версиях аксапты, эта грабля не порождала такого множества проблем, поскольку в старых версиях из кэша обрабатывались только простейшие запросы с запросом из одной таблицы с всеми полями уникального индекса с выражении where. Поскольку 99% процентов запросов по inventSum идут с джойном по inventDim, механизм кэширования не срабатывал, и данные вытаскивались каждый раз из сиквела. В 2012ой поддержали кэширование для джойнов (возможно не для всех случаев, но для части - точно поддержали) и грабля сработала.

В общем - мы до уточнения тупо отключили кэширование inventSum. Похоже что шансы неправильной работы inventOnHand за пределами транзакции - достаточно высоки, а дополнительная нагрузка от показа количеств на складе во всяких отчетах и дисплейных формах - незапредельная.
Кроме того - я вообще не вижу большого смысла включать какое-либо кэширование у такой волатильной таблицы как inventSum. Я еще могу понять режим NotInTTS для заказов и закупок (обычно их только один человек правит и вероятность конфликта невысока), но понять кто и зачем включил этот режим для inventSum (даже если забыть грабли с directSQL) - я не могу...

[Stitch_MS]

Цитата:

Сообщение от fed

...но понять кто и зачем включил этот режим для inventSum (даже если забыть грабли с directSQL) - я не могу...

Возможно, если изменение не очень старое, то коллеги из MS могли бы дать ответ, проверив историю таблицы.

[Владимир Максимов]

Цитата:

Сообщение от Stitch_MS

Возможно, если изменение не очень старое, то коллеги из MS могли бы дать ответ, проверив историю таблицы.

Изменение ОЧЕНЬ старое. Еще в Ax2.5 стояло NotInTTS. Скорее всего, этот режим не то, чтобы включили, а просто не меняли, при переходе на новые версии.

[kashperuk]

А можете выложить проектик, чтобы удобно было воспроизвести?

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

[kashperuk]

А он дисплей метод случаем не кэшировал на форме?

[fed]

Цитата:

Сообщение от kashperuk

А он дисплей метод случаем не кэшировал на форме?

Не дисплей метод. Он для проверки вообще тупой джобик написал с запросом по inventSum. Проектик постараюсь выпросить у него чуть позже...

[kashperuk]

Только что зарепродьюсил с горем пополам.
Узнаю, что можно сделать на данный момент с этим.

[fed]

Цитата:

Сообщение от kashperuk

Только что зарепродьюсил с горем пополам.
Узнаю, что можно сделать на данный момент с этим.

А что за горе то, если не секрет ? Я уверен, что это точно репродьюситься если ты запрашиваешь строку inventSum по itemId и inventDimId, и подозреваю что иногда это случается и на штатных запросах с джойном...

[kashperuk]

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

1. Если InventSum обновляется через DirectSQL (как в случае выше), из другого connection
2. Если InventSum обновляется через другой UserConnection, но почему-то только если это происходит из другого клиента (неважно на сервере или клиенте).

Помогает flush таблицы, но в первом случае он обязательно должен выполняться на сервере

[kashperuk]

Итого, в 6.2 его не пофиксили, потому что уже слишком поздно.
Но я настоял на том, чтобы попробовать его пофиксить через SE канал, как hotfix.
Как заинвестигейтим хороший фикс, дам знать.

[fed]

Мне кажется, что лучший фикс - это запрет кэширования inventSum. Просто не могу ни одной практической ситуации придумать, где это кэширование было бы полезно.

[Pustik]

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

[Pustik]

ох ты, сейчас внимательно рассмотрел - конкретная бага

[BAx]

У нас подобная бага была ( Ax3 SP4 Oracle 11).
Проблема решилось при CasheLookup = None.
Плюсом заметно сократились касты в запросах к этой табл.

[kashperuk]

Кстати, одной из причин не фиксить это прям сейчас было отсутствие SE багов про это.
Здесь уже упомянута 2 раза такая проблема - почему никто не зарепортил на MS Connect?

[Logger]

Цитата:

Сообщение от BAx

Плюсом заметно сократились касты в запросах к этой табл.

А это-то почему ?

[kashperuk]

и что вообще такое касты?

[BAx]

Цитата:

Сообщение от Logger

А это-то почему ?

Извиняюсь, хотел написать не "касты", а costы.
Уточню: заметно сократилось время выполнения запросов при обращении к InventSum как на чтение, так и на update. Косты замерял в PL-SQL developer. Рассинхронизация данных до этого наблюдалась между АОСами.
Связано это с тем, что данная таблица у нас практически постоянно апдэйтится (одна и та же запись), причем с разных АОСов. К тому же она немного шире, чем в стандарте (свои доработки). Часто наблюдалась ситуация, когда транзакции выстраивались в очередь и нервно-курили в ожидании завершения какого-нибудь относительно долгого запроса на update.

[Vadik]

Цитата:

Сообщение от BAx

Извиняюсь, хотел написать не "касты", а costы.
Уточню: заметно сократилось время выполнения запросов при обращении к InventSum как на чтение, так и на update. Косты замерял в PL-SQL developer

Меняем кэширование на сервере приложений - меняются косты на сервере БД ?

[BAx]

Цитата:

Сообщение от Vadik

Меняем кэширование на сервере приложений - меняются косты на сервере БД ?

и да и нет...
если взять отдельный запрос - то план исполнения и косты одинаковые естественно будут.
Но если смотреть в целом с учетом взаимных блокировок (а БД надо получить актуальные на данный момент времени данные, для чего синхронизировать инф из кэша), то суммарная разница в костах (не по запросам) в разы отличается. к таму же при сильной загузке видны блокировки и переполнение tmp tablespace При полном отключении кэширования таблицы на АОСе/клиенте данные сразу пишутся в БД (точнее в кэш БД, но это уже не важно. главное все клиенты видят синхронизированные данные).