Configuring Arbortext Publishing Engine > Understanding Queuing on the Arbortext PE server > How Queuing Works
  
How Queuing Works
Queuing stores transactions for processing at a later time. The queue’s configuration criteria determine when its transactions will be processed. Because parameters can interact with each other, it’s important to set up a test area while you are configuring your queues.
A request to queue a transaction can come from a variety of clients, such as Arbortext Editor users, custom applications, or web browsers. In each case, the initial response from the Arbortext PE server is to notify the client that the request has been queued and to return the assigned transaction ID. This initial notification can be returned in HTML or XML form.
A Queue Manager is the queuing gatekeeper for incoming requests. A Queue Manager examines a request and determines whether to offer it to queues, and then offers it to any configured Arbortext Publishing Engine queues until one accepts it or they all refuse it. When a queue accepts the request, the request becomes a transaction which is stored in the queue until the Queued Transaction Scheduler can execute it (see The Queued Transaction Scheduler for information).
The queue configuration determines how and when queued transactions are available for the Queued Transaction Scheduler to process. Queued transactions are made available during a queue's active time interval. When a transaction is executed, the result is stored in the active transaction directory, and the transaction request is deleted from the queue. Configuration criteria determine this active time interval, order of transaction processing within the queue, simultaneous execution, and so forth.
There is a distinction between a Queue Manager and queues. A Queue Manager controls what gets queued. However, a queue controls how queued transactions are handled, such as their order of processing, when the Queued Transaction Scheduler is allowed to execute them, and other conditions. In distinguishing between Queue Managers and Queues, custom code could determine which requests get queued without having to worry about how queued transactions are stored. Custom code could also control how queued transactions are handled without having to worry about which transactions get queued.
Resource allocation and consumption is managed according to the following:
An Arbortext PE sub-process pool will only allocate an Arbortext PE sub-process to the Queued Transaction Scheduler if no immediate requests are waiting for an Arbortext PE sub-process from that pool.
The maxConcurrentQueuedTransactions global parameter can set the number of transactions that are allowed to execute simultaneously overall. See The Global Active Transaction Parameters for information.
The max-concurrent-transactions queue attribute (set for an individual queue) can set the number of transactions that are allowed to execute simultaneously from that queue. See The max-concurrent-transactions Attribute for information.
The maxConcurrentQueuedTransactionsArbortext PE sub-process pool attribute can set the number of Arbortext PE sub-processes from that pool that can be simultaneously allocated to the Queued Transaction Scheduler. Setting this value to zero prohibits queued transactions, and reserves the entire pool only for immediate transactions. See The maxConcurrentQueuedTransactions Attribute.
When you are ready to set up queuing, the following sections explain the configuration parameters you might use:
Active transaction parameters described in The Global Active Transaction Parameters.
Transaction archive parameters described in The Global Transaction Archive Parameters
Global queuing parameters described in The Global Queuing Parameters.
Queue parameters described in Specifying Queues.
You can also set up Arbortext PE sub-process pools that are dedicated to taking only immediate requests or only queued requests. Refer to Configuring Sub-process Pools for information.
* 
For backward compatibility, Arbortext PE Request Manager always handles requests from older versions of Arbortext Editor as immediate (rather than queued) requests by default (which requires no special configuration).