The scheduling-option Attribute
Specifies how queued transactions should be executed.
• strict-complete
No transaction shall start executing until all previous transactions on the queue have finished executing, including held transactions. Note that choosing this value means that transactions from this queue will never execute in parallel.
• strict-parallel
No transaction shall start executing until all previous transactions on the queue have started executing.
• relaxed (the default)
A transaction may start executing if earlier transactions on the queue are not able to execute for some reason.
By default, the relaxed approach is to allow the Queued Transaction Scheduler to try executing transactions in order, but place a higher emphasis on keeping busy and executing transactions rather than ensuring that transactions are processed in order.
Example
A queue contains three transactions, in order: A, B, and C. The Queued Transaction Scheduler scans the queue looking for a transaction to execute. Transaction A can’t be executed for some reason (it might be held or it might be waiting for an Arbortext PE sub-process to become available from a specific pool). The Queued Transaction Scheduler would obey the queue’s configuration for strictness:
• If a queue is configured strict-complete or strict-parallel, the Queued Transaction Scheduler would not execute transaction B, because A could not run.
• If the queue is configured relaxed, then the scheduler would execute transaction B instead.
Example
A queue contains three transactions, in order: D, E, and F. The Queued Transaction Scheduler scans the queue searching for a transaction to execute. Transaction D is executing. If the queue is configured strict-complete, transaction E can’t run because D is not finished. If the queue is configured strict-parallel or relaxed, transaction E could be started.