Обработка входящих сообщений

[Maximin]

Цитата:

Да, кстати, если обмен директивами идет через таблицу, то ее ни в коем случае не надо кешировать. Вам ведь надо всегда читать актуальную информацию, а не то, что сохранено в кеше.

Еще как надо! Это сильно разгружает БД. Далее.. При режиме кэширования EntireTable таблица лежит на AOS и в остальном ведет себя как при режиме кэширования Found. Соответственно, скэшируются результаты поиска только найденных строк для сообщений, итак предназначавшихся конкретному клиенту. А раз так - то при нахождении такой записи и обработке сообщения его сразу же удалят и кэши буду сброшены.

Что же касается использования Info для обработки таймаутов - то поддерживаю. У нас использовались обработчики на формах только из-за небходимости отображать сообщения там же - в формах.

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

Цитата:

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

Еще как надо! Это сильно разгружает БД. Далее.. При режиме кэширования EntireTable таблица лежит на AOS и в остальном ведет себя как при режиме кэширования Found. Соответственно, скэшируются результаты поиска только найденных строк для сообщений, итак предназначавшихся конкретному клиенту. А раз так - то при нахождении такой записи и обработке сообщения его сразу же удалят и кэши буду сброшены.

Ну, у меня прямо противоположные выводы Вы сделали ряд допущений, о которых автор темы вообще-то не говорил.

1. Какие основания есть предполагать, что после "обработки" запись будет удалена и кеши будут сброшены? Историю сохранять не надо? У автора речь идет вовсе не о сообщениях, а о некоем "запуске класса" (понимай - обработке), что просто в обязательном порядке требует журналирования.

2. Какие основания есть предполагать, что все происходит на одном AOS? Если с одной и той же базой работают несколько AOS, то кеширование таблиц - это "смерть" подобной системы. Один AOS просто не увидит модификаций, сделанных другим AOS.

[raniel]

Спасибо всем...неплохую пищу для ума подкинули....похоже теперь всё выйдет. Зачем всё это надо я расписывать не буду(да и не думаю что это на самом деле интересно). Главное методика есть.... (Война фигня, главное манёвры) :-)
Ещё раз всем спасибо!

[Maximin]

1. История и само сообщение - лежит в отдельной таблице. В "сигнальной" таблице - только флаг о новом сообщении. Увидел - сбросил.

2. Прочитайте, наконец, главу из Inside Dynamics 4.0 про режимы кэширования таблиц и не позорьтесь.

Цитата:

Сообщение от Владимир Максимов

Ну, у меня прямо противоположные выводы Вы сделали ряд допущений, о которых автор темы вообще-то не говорил.

1. Какие основания есть предполагать, что после "обработки" запись будет удалена и кеши будут сброшены? Историю сохранять не надо? У автора речь идет вовсе не о сообщениях, а о некоем "запуске класса" (понимай - обработке), что просто в обязательном порядке требует журналирования.

2. Какие основания есть предполагать, что все происходит на одном AOS? Если с одной и той же базой работают несколько AOS, то кеширование таблиц - это "смерть" подобной системы. Один AOS просто не увидит модификаций, сделанных другим AOS.

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

Цитата:

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

1. История и само сообщение - лежит в отдельной таблице. В "сигнальной" таблице - только флаг о новом сообщении. Увидел - сбросил.

Это всего-лишь одна из возможных стратегий. Имеет как достоинства, так и недостатки. Возможны другие варианты реализации. Например, журнал и сигнальная таблица - это одна таблица. Зависит от задачи.

Цитата:

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

2. Прочитайте, наконец, главу из Inside Dynamics 4.0 про режимы кэширования таблиц и не позорьтесь.

Гм... Ну, не считая того, что в данной теме речь идет об AX3.0, причем неизвестно какой версии (синхронизация кеша с базой данных реализована начиная с версии AX3.0 SP2) приведу пример того, что происходит у нас.

У нас AX2.5 SP3. Несколько AOS подключенных к одной базе данных. При режиме кеширования EntireTable модификации, сделанные на одном AOS не видны на другом. По той причине, что нет синхронизации кеша с базой данных. Напомню, это стало возможным только в AX3.0 SP2.

PS: Не стоит считать оппонента идиотом. Разумнее предположить, что он работает в других условиях. У него другой опыт. Или просто чего-то не договаривает. Вот как Вы, например