|
![]() |
#1 |
Боец
|
Цитата:
Сообщение от Rardd
![]() Извините за задержку с ответом. Задача в следующем:
Есть сущность которую нужно выгружать, и есть ситуация когда эта сущность настолько велика, что ее формирование это десятки часов (система достаточно мощная). И задача была в том, что бы разбить выгрузку этой сущности на потоки что бы снизить общее время ее генерации так как есть записи которые выгружаются 10 секунд, а есть записи которые выгружаются 10 минут, и пришли к выводу что нужно разбить выгрузку на задачи (потоки). Каждый поток записывает резульатат в таблицу (единственный выход синхронизации потоков). Потом, когда все потоки отработали, идем в таблицу и создаем из записей json, который с помощью Custom Service можна забрать. Вот собственно и все ![]() Про Threads: у меня сложилось впечатление, что в силу неумения правильно готовить этот класс, просто советуют его не использовать. Его сложно отлаживать, нужно засинкать потоки, оптимизировать их количество, корректно вернуть результат из потока + вероятно вернуть infolog и т.д. Все это нетипичное для повседневных задач программирование, отсюда его не любят. Однако, работу он свою выполняет корректно, без мифических глюков и не раз выручал. В CIL он действительно не работает, но и не очень-то нужно. Threads больше подходит для интерактивных задач. Но для вашей задачи лучше использовать Batch это будет и проще и отказоустойчивое. |
|
|
За это сообщение автора поблагодарили: user_ax (2), Sergey Petrov (1). |
![]() |
#2 |
Banned
|
Цитата:
Кстати как вариант я бы еще рассматривал средства СУБД и хранимые процедуры. |
|
![]() |
#3 |
Участник
|
Цитата:
Сообщение от DSPIC
![]() Вам идеально подходит Batch в режиме multithread http://www.artofcreation.be/2010/10/...ultithreading/ лучше для задачи не придумаешь. BatchJob будет сплититься на потоки, один из которых master, после того как все остальные отработают будет осуществлять выгрузку. Из преимуществ - в случае «пропало электричество» продолжит свою работу + логи, регулирование количества потоков, повтор в случае отказа, нотификация по завершению и т.д. Одним словом - все плюшки батча.
Про Threads: у меня сложилось впечатление, что в силу неумения правильно готовить этот класс, просто советуют его не использовать. Его сложно отлаживать, нужно засинкать потоки, оптимизировать их количество, корректно вернуть результат из потока + вероятно вернуть infolog и т.д. Все это нетипичное для повседневных задач программирование, отсюда его не любят. Однако, работу он свою выполняет корректно, без мифических глюков и не раз выручал. В CIL он действительно не работает, но и не очень-то нужно. Threads больше подходит для интерактивных задач. Но для вашей задачи лучше использовать Batch это будет и проще и отказоустойчивое. делал похожую задачу используя мультипоточность , которую предлагает стандартный runBaseBatch - все отлично работает, без каких-либо нареканий. И что самое важное - выглядит код действительно проще , нежели с использованием Threads классов. |
|
Теги |
async, ax2012, ax7, cil, d365 for operations, lock, thread |
|
![]() |
||||
Тема | Ответов | |||
AX2012R3: полная синхронизация данных POS-магазина | 10 | |||
Синхронизация SP4 -> SP5 | 4 | |||
навязчивая синхронизация | 11 | |||
Репликация и синхронизация | 12 | |||
синхронизация с outlook | 7 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|