Разработка в кластере АОС

[ravil]

Готовлюсь сдавать экзамен по АОС. Если все АОСы остановить, модифицировать в двухзвенке, удалить у всех клиентов файлы кэша, тогда я полагаю проблем не будет.
Но важно знать, как теоретически правильно вносить модификации в кластерном окружении, а не как этого можно достичь практически. Может быть есть варианты без перезапуска АОС, вот что беспокоит. Про меточные файлы я читал однозначное указание на необходимость перезапуска АОС, чтобы изменения вступили в силу. А вот относительно элементов АОТ у меня сомнения. С одной стороны, в документе по версии 2.5 пишут:

One way to update the cache would be to restart the AOS'. However, this would not be a feasible solution, as it would often require multiple users to restart. In certain situations, it is necessary to ship application changes to a running multi-AOS environment, and so a solution is needed.

The AOT contains a class called SysFlushAOD. This class flushes the application objects from the cache on the tier where it is executed. Executing SysFlushAOD on the client will flush the client application object cache, whereas executing the class on the server will flush the shared server application object cache.

To update the servers object cache, follow the procedure below:
1. Create a new Action Menu Item which activates the SysFlushAOD class.
2. Set the menu item's RunOn property to Server.
3. Add the menu item to the Tools\Development menu by adding it to the Menu named DevelopmentTools.

Once changes have been made to the application, it is possible to update the AOS' by connecting to each individual AOS, and activating the menu item. This will cause the server to flush the current application object cache. Some clients might need to be restarted in order to obtain the new, updated application object.

То есть как бы можно вносить изменения не перезапуская АОС. Но на 3.0 sp3 у меня такой фокус не прокатывает. То ли глюк, то ли так и должно быть.

А вот в другом документе читаю: (для какой версии, не указано)

All development must pass the same AOS. This means no 2-tier development and no other AOS running against the same application at the time of modification. Use 3-tier fat client instead of 2-tier when 3-tier thin client is not sufficient for testing or developing.
When Axapta claims that it needs to be restarted in relation to label file creation, note that the AOS needs to be restarted. It is not enough to restart the client.

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