Несколько AOS: синхронность изменения объектов

[Андрей К.]

Всем привет.
Мы используем 2 AOSа привязанных к одному приложению, в связи с чем появилась проблема при ведении разработок.
Пример такой: на AOS №1 я меняю название у поля таблички, после чего захожу на AOS №2 и очень долго не вижу изменений (в репозитарии поле таблички имеет старое имя).

Выход из ситуации найден один единственный:
1. сначала запуск на стороне сервера (директива server в вызывающем методе):

sysFlushDictionary::doFlush() // обновление словаря

2. затем на стороне клиента (директива client в вызывающем методе) запуск следующих команд:

xSession::removeAOC(); // чистим клиентский кеш
sysTreeNode::refreshAll(); // обновляем тринод
sysFlushDictionary::doFlush(); // обновление словаря
sysFlushAOD::doFlush(); // обновление АОД
xSession::updateAOC(); // обновляем клиентский кеш

3. восстанавление объекта (км таблички - Восстановить)

Единственное ли это верное решение для данной проблемы? AOSы не объединены в кластер. Решит ли данную проблему объединение AOSов в кластер?
Ну и собственно не могли бы знающие люди пролить свет на нюансы кеширования, которые полезно было б знать.
Спасибо

[Андрей К.]

Ответ нашелся в стандарте разработки <стыд>:

Цитата:

1.8. В случае, когда для работы с приложением создано два экземпляра АОС, при завершении разработки необходимо обновить кэш на обоих экземплярах АОС, запустив следующие операции:
o «Сервис / Средства разработки / Объекты приложения / Обновление словаря»
o «Сервис / Средства разработки / Объекты приложения / Обновление данных»

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

[kornix]

Извиняюсь за глупый вопрос - а для чего вести разработку на 2-х АОС-ах? У вас более 60 одновременно работающих разработчиков?

[Андрей К.]

Цитата:

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

Извиняюсь за глупый вопрос - а для чего вести разработку на 2-х АОС-ах? У вас более 60 одновременно работающих разработчиков?

у нас - нет
у клиента есть жалобы, что когда пакеты изменений ставятся на АОС1 , то АОС2 не видит новые изменения - ну ясное дело, он видит только свой кеш

интересно а как часто этот кеш автоматически обновляется?

[kornix]

А.. Тогда как вариант можно заливать на один AOS, делать на нем инкрементную компилляцию, а ночью перезапускать АОС'ы

[Logger]

Насколько я помню для таблиц Обновление словаря и Обновление данных не всегда помогает. Но зато помогает компиляция, восстановление и повторная компиляция.

[Андрей К.]

Цитата:

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

Насколько я помню для таблиц Обновление словаря и Обновление данных не всегда помогает. Но зато помогает компиляция, восстановление и повторная компиляция.

вот в случае с таблицами синхронизацию надо применять

[Logger]

Цитата:

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

вот в случае с таблицами синхронизацию надо применять

не помогает.
На других аосах видны Unknown поля. Нужно на каждом аосе компильнуть и восстановить соответствующую табличку, чтобы кеш сбросился.

[DSPIC]

Не знаю, работает ли это на практике, но судя по всему, нужно сразу после накатывания модификаций, через меню сервис последовательно вызвать
1. Средства разработки\объекты приложения\обновить АОD
2. -\\- обновить словарь
3. -\\- обновить данные

В каждом из этих случаев "взводится" соответствующая команда всем АОСам через вызов SysEvent::fireEvent(SysEventType::XXXXXX), где XXXXXX = [FlushAOD | FlushData | FlushDictionary | ...]); Команда помещается в таблицку табличку SysEvent.

Каждый из АОСов в отдельном потоке потоянно "слушает" эту таблицу и при появлении в ней команды исполняет её посредством класса "SysEventHandler", который инициализируется на стартапе АОСа. Таким образом, проблема сброса кэша и подтягивания изменений должна решаться для АОСов.Ну а клиентам придется перезайти в систему, хотя, можно подумать в сторону простейшего допила этой функции для клиентских сессий. (но, видимо, неспроста функциональность намеренно ограничена только для серверных сессий - см. код)

Этот механизм реализован как минимум в AX2009. Если механизм эффективен, то для старых версий навскидку можно реализовать по аналогии.

[gl00mie]

Цитата:

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

вот в случае с таблицами синхронизацию надо применять

О, да! Вспомнилось, как однажды было добавлено поле в одну из тех таблиц, которые синхронизируются при старте сессии. На одном АОСе синхронизировали таблицу после создания поля - оно в базе появилось, на другой АОС зашел пользователь, табличка синхронизировалась - поле из базы пропало, и так ндцать раз... А еще очень "весело" может получиться, если добавить поле в таблицу, которая постоянно используется в приложении (какая-нить SalesParameters): добавили, не успели синхронизироваться, зашел пользователь, "увидел", что в таблице новое поле, давай его указывать в select'ах, а СУБД грит, отвали, нету такого поля в таблице - и так у пользователя на любой чих начинает лезть ошибка, и ничего не работает.
Это я все к тому, что на рабочей базе при нескольких работающих АОСах и работающих пользователях схему данных лучше не менять - вообще. Ну либо очень хорошо взвешивать все "за" и "против".

Цитата:

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

В каждом из этих случаев "взводится" соответствующая команда всем АОСам через вызов SysEvent::fireEvent(SysEventType::XXXXXX), где XXXXXX = [FlushAOD | FlushData | FlushDictionary | ...]);

К сожалению, это все не поможет обновить кэш объектов приложения на клиентах. Я как-то под отладчиком наблюдал, как мне прежде казалось, совершенно невероятную ситуацию: класс-наследник RunBase переключался между клиентом и сервером, там и там дергая определенный метод (кажется, это был validate), и при этом на клиенте код этого метода был один, а на сервере - другой. Так что кэширование кода на клиентах - штука опасная, и забывать про него нельзя.

[lev]

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