Проблема с кэшированием в Аксапте

[snirk]

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

Пример 1:
В таблице есть поле A, которое отображается на форме. И на форме, и через Обозреватель Таблицы видно, что значение поля для одной из строк = false, а при работе одного из методов, который правильно находит эту строку, значение этого поля = true (видно в Debugger-e). Совершенно непонятно откуда берется такое значение.
Проблему удалось решить очистив кэш на сервере и перезагрузив клиента.

Пример 2:
Изменил код в методе одного из классов, сохранил, откомпилировал. Но при работе с моего компа вызывается старый, неизмененный метод (Debugger в него сваливается). При этом на других компах видят мой новый метод. Перезагрузка Аксапты не помогла. Проблему так и не решили.

И куча похожих багов, которые повторяются постоянно...

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

Если у кого есть мысли, очень прошу высказаться - проблема серьезно мешает работать.

Заранее спасибо.

P.S. Ax 3.0 SP2

[kashperuk]

Ну, здесь нового ничего нет, и все работает, как и должно.

По второй проблеме:
Если уж ведете разработку в 3ехзвенке, так извольте и кэш чистить

К примеру, вот такой код можно использовать

    xSession::removeAOC();
    SysTreeNode::refreshAll();
    SysFlushDictionary::main(_args);
    SysFlushAOD::main(_args);
    SysFlushData::main(_args);
    xSession::updateAOC();

По первой проблеме:
Есть хороший документ по этому поводу:
AX-300-TIP-058-v01.00-ENUS - Asynchronous Cache Flushing in Microsoft Business Solutions–Axapta 3.0 SP2
Почитайте

[kashperuk]

Еще обратите внимание на вот это сообщение
Тест Columbus IT/Microsoft: решение "Юнимилк" способно обслуживать 1300 пользователей

[snirk]

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

Вообще-то мне кажется, что это не две разные проблемы, а разные проявления какой-то одной.

[snirk]

За инфу спасибо.

[kashperuk]

Цитата:

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

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

Вообще-то мне кажется, что это не две разные проблемы, а разные проявления какой-то одной.

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

2. этот код надо не добавлять в нужный метод
Этот код нужно повесить на какой-то пукнт меню, и вызывать принудительно после внесения изменений.

[glibs]

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

У вас проблемы возникли на стандартной функциональности или на ваших модификациях? Решением может быть пересмотр метода кэширования на таблице.

Стандартные настройки Аксапты — не догма. На многих инсталляциях в последнее время на период настройки и начальной эксплуатации системы я, например, на плане счетов снижаю уровень кэширования до found. Иначе при редактировании плана счетов даже в однопользовательском режиме возникают ошибки обновления записи мною же ранее обновленной.

Так что думайте и экспериментируйте.

[snirk]

Дело в том, что проблема возникла не на новой функциональности, а на той функциональности которая уже долго работала без таких проблем.
И даже сучетом политики кэширования в Аксапте непонятна следующая ситуация:
Пользователь 1 изменил данные
прошло время ...
Пользователь 2 все равно видит какие-то старые данные, а
Пользователь 3 - новые, измененные

[snirk]

Уровень кэширования стоит - NotInTTS

[kashperuk]

Вырезка из документа, на который я указал выше:

Цитата:

All in all, the new cache flush mechanism consists of:
• Every session records updates/inserts to a private list of tables updated
• When a session commits, its session private list is merged into an AOS global list of tables updated.
• At an interval set by the user, the AOS global list is written to the database, in a special row in SysLastValue table.
• At a user configurable interval, querying against cached tables will read the database stored list. If the list from the database has a higher cache version for the queried table, the local cache is flushed. This is on a table basis, so only if the local cache for this one table was used, and if the table was actually updated, will the cache be flushed prior to the read.
• All Thin clients do NOT read the database flush list; instead they query the AOS for its global list of updated tables. This ensures that a Thin Client will not conclude that a cache should flush at another frequency than the AOS does. If the client reads the information from the database it would occasionally read the flush info slightly before the AOS did. This caused the Client to flush the local cache before the AOS refreshed its cache, and so the client would read stale data from the AOS cache, but would have the new Cache Version registered, and so would be one version ‘behind’.
• The above AOS mechanism applies for all Fat Clients as well.
• The above Flush and Test interval is derived from a single MaxCacheSync time parameter and are both half of the MaxCacheSync time.
The net effect of the above is:
• All caches, be it on AOS, Fat Client, or Thin Client will be current within the MaxCacheSync time.
• Inactive clients (or AOS’s) will not cause extra network traffic (that is after half the MaxCacheSync has expired, no additional network traffic will occur).
• Due to the asynchronous write of flush info, network traffic is minimized, even though a lot more tables are now included in the flush report.

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