[gl00mie]

Цитата:

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

в АХ делают вот так вот чтобы создать потоки:

// create a new instance of the batch task class
klForUpdateCustomersMultiThreadTask = KlForUpdateCustomersMultiThreadTask::newcustTable(custTable);
// add tasks to the batch header
batchHeader.addRuntimeTask(klForUpdateCustomersMultiThreadTask, this.parmCurrentBatch().RecId

Вопрос: Сколько поток создастся в этом случае?

В приведенном примере не создаются потоки - в нем создаются пакетные задачи по аналогии с тем, как в .NET создаются Task'и в рамках TPL. Сколько под эти задачи создать потоков, решает пакетный сервер (или серверы) на основе своих настроек и загрузки другими пакетными заданиями. Пакетным заданиям назначается пакетная группа, которую по умолчанию наследуют пакетные задачи, создаваемые в runtime, также пакетные группы назначаются для обработки пакетным серверам. Исходя из этого, число потоков для выполнения задач определенной пакетной группы ограничено сверху тем, скольким пакетным серверам эта группа назначена для обработки и какое число потоков настроено для каждого из этих серверов.

Цитата:

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

А как сделать чтобы было вот так вот?

public class TestThreadPool {  
     public static void main(String[] args) {  
        ExecutorService executor = Executors.newFixedThreadPool(5);//creating a pool of 5 threads

Чтобы жестко ограничить пакетную обработку определенным числом потоков, есть два основных подхода:

• выделить под обработку отдельную пакетную группу, эту группу назначить пакетному серверу и ограничить его число потоков под пакетные задачи. Минус подхода в том, что пакетные сервера - ресурс платный, и ставить новый пакетный сервер под ту или иную обработку в общем случае накладно.
• написать пакетную обработку таким образом, чтобы она при запуске узнавала, сколько отдельных задач ей надо обработать (клиентов, накладных, номенклатур, etc), затем паковала эти свои задачи в "пакеты" (bundles) и на каждый пакет создавала уже пакетную задачу - в этом случае число потоков сверху будет ограничено числом созданных пакетных задач (т.е. числом "пакетов", на которые нарезана обработка). Минус этого подхода в усложнении кода пакетной обработки, но зато упрощается администрирование.

См. также Batch Parallelism in AX –Part - I. К большому сожалению, пакетная инфраструктура не умеет ограничивать число потоков для задач пакетной группы в рамках одного пакетного сервера.