во-первых, спасибо что открыли новую ветку про ax2012
надеюсь это было осознано, поскольку ТА ветка была про DAX09.
Цитата:
Сообщение от
Perc
Поскольку я как раз один из тех, кто ничего не делает со своими классами на основе RunBaseBatch, перед запуском их на пакетнике Акс2012. Поэтому прочитав коммент, решил посмотреть код - в чем собственно проблема..
1. Типичное мое использование прогресса в RunBaseBatch это где-то в run начать this.progressInit("Обработка", 1, #AviUpdate)... Проваливаемся и видим, что в этом случае по умолчанию в в серверный SysOperationProgressServer передается _bypass=true. А это значит никакая логика по отображению прогресса не отрабатывает. В SysProgress ничего не пишется и ничего не читается. Мое задание на сервере вообще никак дополнительно не нагружает его своим прогрессом.
...
В итоге получаем вопрос. 8 обновлений в 0,5 сек - это действительно может стать бутылочным горлышком? С учетом, что у таблицы SysProgress оптимистическая конкурентная модель и все 8 процессов обновляют разные записи.
Ну если не 8, то сколько станет проблемой, если сложить все задания со всех пакетные серверов?
Прекрасно!
Вы замечательно описали то, к чему пришли разработчики Аксапты с прогрессом на сервере.
В 2012 это действительно так.
Посмотрите в прошлых версиях
Цитирую себя дословно:
Цитата:
Сообщение от
mazzy
выше я говорил, что некоторые на проектах запрещают использовать ProgressBar вообще.
конечно же не для того, чтобы усложить жизнь пользователей
а именно из-за того, что натыкаются на это бутылочное горлышко.
в основном проблема возникает, когда программист отлаживает RunBaseBatch на клиенте с прогрессбаром, а потом этот же класс безо всяких модификаций начинает выполняться в пакетнике.
есть разные подходы для решения проблемы с прогресс-баром на сервере.
что-то сделано и в Аксапте - обратите внимание, как забавно работает процент выполненных работ в пакетных заданиях