Многопоточное вычисление дисплейных методов

[Ace of Database]

Привет всем!
Столкнулся с одной формой, на которой навешано куча тяжелых дисплейных методов. Из-за которых блокировалась работа пользователей. cacheAddMethod не сильно помогал, так как даже первый незакешированный вызов блокирует интерфейс на несколько десятков секунд при каждой прокрутке страницы на гриде.

Целью моих экспериментов было создать такое кеширование дисплейных методов, которое не блокирует пользовательский интерфейс даже при первой прорисовке данных.

Во вложении проект для AX2012.
В проекте есть тестовая форма, которая демонстрирует использование многопоточного вызова дисплейных методов. Данные перерисовываются не сразу, а постепенно, как будто вы находитесь на веб-странице.
На тестовой форме представлен пример вызова дисплейного метода, возвращающего вещественное число, и дисплейного метода, возвращающего строку.
Чтобы применить пример к любой другой форме, надо
1) Добавить на вашу таблицу все кешируемые дисплейные методы, которые есть на вашей форме, но нет в вашей таблице
2) Вызвать эти дисплейные методы из дисплейных методов на вашей форме, используя предлагаемый пример. В тесте вызываются дисплейные методы "grossWeight" и "itemName" из таблицы InventTable
3) с тестовой формы взять те участки кода, которые обрамлены комментариями

    //Дисплейные методы -->
    ........
    //Дисплейные методы <--

Внимание: если поставить точку останова внутри дисплейных методов таблиц, которые вызываются из другого потока, то отладчики начнут интенсивно размножаться для каждого нового потока
На дисплейные методы формы точки останова ставить можно, т.к. они выполняются в главном потоке.

[mazzy]

а выводить данные из формы в эксель будет?
а в отчет можно?
а в экспорт во внешние системы?

[Ace of Database]

Цитата:

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

а выводить данные из формы в эксель будет?
а в отчет можно?
а в экспорт во внешние системы?

1) В эксель выводится так же как обычно, но только те поля, которые успели вычислиться.
2) Фишка в том, что на форме реализован таймер, который достает время от времени вычисленные в других потоках данные. Поэтому отчет можно сформировать только как слепок данных с формы
3) То же самое, что и пункт 2

[Ace of Database]

Обновил проект.
Пофиксил интересный баг с повторным использованием переменной типа AnyType, инициализированной для другого типа данных.
В результате переставало работать, если на одной и той же форме были строковые и числовые дисплейные методы

[Ace of Database]

И еще раз обновил

[mazzy]

Цитата:

Сообщение от Ace of Database

1) В эксель выводится так же как обычно, но только те поля, которые успели вычислиться.

т.е. нужен какой-то статус на форме, который показывает, что все вычислилось?

[Ace of Database]

Цитата:

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

т.е. нужен какой-то статус на форме, который показывает, что все вычислилось?

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

[TasmanianDevil]

Интересная идея.
2012-й под рукой нет, зырил код через блокнот и вполне мог упустить кое-что, но тем не менее осталось впечатление, что механизма обновления кэша нет, т.е. после обновления записи (в т.ч. полей, на основе которых рассчитывается дисплейный метод) будет возвращаться то же самое значение.
В принципе это можно реализовать дополнительной мапой { [tableId, recid] -> recVersion} по отработанным табличным переменным.
При несовпадении recVersion у отработанной табличной переменной (по данным доп. мапы) и переданной - чистить кэш по ней и запускать отработку метода снова с обновлением результата в кэше и доп.мапе.

[Ace of Database]

Механизм очистки кеша целиком есть, в примере он просто не использован
Чтобы очистить весь кеш и заставить все вычисляться заново, надо вызвать метод clearCache() в классе zThreadDisplayMethod

Очистка кеша для отдельных записей для меня не представляется полезной, т.к. такие дисплейные методы обычно работают очень быстро, и вычислять их в отдельном потоке не имеет смысла.
Но, если все-таки надо очистить кеш только для нужной записи в таблице для конкретного дисплей-метода, то можно удалить запись из двух мапов - mapResult и mapCalled класса zThreadDisplayMethod. А также из таблицы zThreadResultTable для того же самого ключа, что и для мапов, но еще дополнительно отфильтровав по коду сессии, который хранится в переменной session в классе zThreadDisplayMethod.

[Ace of Database]

Я оговорился, в примере полная очистка кеша используется. В методах ExecuteQuery() и Research() в источнике данных на форме. То есть, подразумевается, что раз пользователь нажал F5, то все надо заново пересчитать.

[Ace of Database]

Выяснилось, что метод cacheAddMethod на источнике данных формы вызывает один раз дисплейный метод для каждой отображаемой записи. Даже если поле скрыто на форме.
Поэтому, если используется самописное кеширование дисплейных методов через Map, то лучше убрать cacheAddMethod. А при использовании мгногопоточности вообще получается плавная прокрутка данных на форме.