Как чистите глобальный кэш АОСов?

[Товарищ ♂uatr]

Привет.
Есть глобальный кэш сервера. Серверов N.
Он содержит некий закэшированный объект, крайне чувствительный к актуальности данных.
Данные имеют свойство обновляться M раз в неделю.
У каждого АОСа индивидуальный кэш (речь о 2009 версии Аксапты).
Какие способы актуализации кэша могут иметь место? При условии, что её выполнить сразу же после устаревания данных.

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

[Logger]

Речь о кеше с данными или о кеше исполнимого кода ?

[Товарищ ♂uatr]

Объект - код, экземпляр класса.

[Raven Melancholic]

Цитата:

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

Речь о кеше с данными или о кеше исполнимого кода ?

Как понимаю, речь про программные наборы кэша каких-то данных сделанные либо добрым старым стандартным SysGlobalCache, либо какими-то своими способами.

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

Тут вся надежда на пользователей, которые знают, что когда им сказали "сбросьте кэш", воспользовались предложенным разработчиками механизмом.
На скринах с использованием TabAx и без него.[ATTACH][/ATTACH]

[Logger]

Если речь про данные, то п.1 делает ядро, правда, глючно. Периодически этот механизм синхронизации кешей аосов ломается и его чинят (аосы периодически пишут данные в SysLastValue - сообщения друг другу о необходимости сброса кеша). Можно другое ядро- неглючное подобрать.
Если класс аксапты кеширует данные, например как с курсами валют то мне больше всего нравится вот это вариант
О сломанных шестеренках в большом моторе

Если речь об исполнимом коде, то есть способ (первый раз увидел его в сообщении Maximin). После того как проект по живой накатили, запускаем специальную процедуру, она перебирает все аосы, подключается к каждому аосу (запускает клиента аксапты с параметром - имя проекта) и на каждом аосе перебирает узлы проекта и каждый узел компилирует и делает refresh + restore дважды (именно дважды). Это прочищает кеш исполнимого кода аоса.

[Raven Melancholic]

Цитата:

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

После того как проект по живой накатили, запускаем специальную процедуру, она перебирает все аосы, подключается к каждому аосу (запускает клиента аксапты с параметром - имя проекта) и на каждом аосе перебирает узлы проекта и каждый узел компилирует и делает refresh + restore дважды (именно дважды). Это прочищает кеш исполнимого кода аоса.

Вроде для уж совсем гарантии, нужно в проекте не только "каждый узел компилирует", но и "инкрементно компилирует". Правда, если в проекте есть что-то подобное RunBase или в компании, в которой Вы работаете классы TSD, то этот сброс растянется на часы.

Ну и "запускает клиента аксапты" я уже видел - при нескольких АОСах это мультипликация на экране пользователя, который это запустил. Уж лучше, если Акса до 2009 включительно, то "втихую" powershell с использованием NET-Connectir.

[Logger]

Цитата:

Сообщение от Raven Melancholic

Уж лучше, если Акса до 2009 включительно, то "втихую" powershell с использованием NET-Connectir.

Интересный способ. Но мы так не пробовали.
У вас работает ?

А с 2012-й не прокатывает ?
Мы в 12-ке тоже такой подходи применяем, но модифицировали. Вместо компиляции с восстановлением, делаем импорт xpo на каждом аосе. Нужного эффекта достигаем.
За исключением вот этой проблемы
Ax 2012 R2. Поле "не извлечено"
Но мы все неинтерактивные аосы (пакеты, web-сервисы) запускаем с опцией -INTERNAL=NOCURSORREUSE

[Товарищ ♂uatr]

Привет.
Хотел выбрать простое и стабильное решение. Сложилось впечатление, что Pipe сюда идеально подходит.
Плюсом является нативная возможность его работы в асинхронном режиме.
Есть встроенный EventDrillDownPoller, обертка над PipeServer, который можно было слегка переработать для достижения целевого результата.
Вопрос остается только в отправке трафика (если бы) - для этих целей, по идее, подходит PipeClient.
Соответственно создаём pipeServer, pipeClient - отправляем трафик серверу и...ничего.
Читаем документацию по клиенту и поражаемся тем, насколько MS удалось придерживаться концепций "чистого кода":
https://learn.microsoft.com/en-us/do...-finops-dotnet)
Когда код настолько описывает себя, что даже и документация не нужна.
Самое полезное, что было в документации - имя сборки содержащей данный объект "Microsoft.Dynamics.AX.Xpp.Support.dll" (это помогло совершенно в ином вопросе).
Ну и не нашел ничего похожего в данной библиотеке, поэтому сделал необоснованный вывод, что PipeClient и PipeServer ничто иное как обертка над System.IO.Pipes.NamedPipeClientStream и System.IO.Pipes.NamedPipeServerStream соответственно.
Открываем тоже самое по серверу и видим чуть больше информации:
https://learn.microsoft.com/en-us/do...-finops-dotnet
Ну и получается, что MS ограничили возможность коммуникации на инкапсулированном от программиста уровне инициализации объекта.
Никто не запрещает подключить сборку System.Code.dll и отказаться от использования PipeServer и Client Аксапты в пользу аналогов из .Net и они работают - но речь уже не идёт о простом решении, чистов воды кастомизация.

[Raven Melancholic]

Опять же все эти способы помогают при "горячем изменении кода".

Как-то задачу "Уведомить клиентский процесс от том что что-то изменилось" они не решают.

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