Publishing Engine Programmer's Guide > The Arbortext Publishing Engine Request Manager > Predefined Dynamic Components > Pre-Defined Queues > Forcing a Transaction to Execute Next
  
Forcing a Transaction to Execute Next
Each of the previous sections describes circumstances that might make a transaction ineligible for execution. It is possible to bypass many of these restrictions and force a transaction to execute before any other transactions on any queue.
A web client can issue an f=qt-execute request to designate a transaction to be the next to execute. This transaction is then identified by a marker stored in the Queued Transaction Scheduler. Only one transaction can be designated in this way. If transaction A is marked and then transaction B is also marked, transaction B becomes the next transaction to execute. Transaction A returns to its normal course of processing without special handling.
The designation ignores the queue’s enabled and active states, and it also ignores the transaction’s hold status and scheduling options. However, it will obey the global maxConcurrentQueuedTransactions parameter setting, the maxConcurrentQueuedTransactions setting on any Arbortext PE sub-process pool, and the max-concurrent-transactions setting on the queue containing the transaction.