Each execution class is associated with a different priority:
Tasks assigned to EC1 are placed in a high-priority run queue.
Tasks assigned to EC2 are placed in a medium-priority run queue.
Tasks assigned to EC3 are place in a low-priority run queue.
An engine looking for a task to run first looks in its own high-priority run queues, then in the high-priority global run queue. If there are no high-priority tasks, it checks for medium-priority tasks in its own run queue, then in the medium-priority global run queue, and finally for low-priority tasks.
What happens if a task has affinity to a particular engine? Assume that task 7 in Figure 4-3, a high-priority task in the global run queue, has a user-defined execution class with high priority and affinity to engine 2. Engine 2 currently has high-priority tasks queued and is running another task.
If engine 1 has no high-priority tasks queued when it finishes processing task 8 in Figure 4-3, it checks the global run queue, but cannot process task 7 due to the engine binding. Engine 1 then checks its own medium-priority queue, and runs task 15. Although a System Administrator assigned the preferred execution class EC1, engine affinity temporarily lowered task 7’s execution precedence to below that of a task with EC2.
This effect might be highly undesirable or it might be what the performance tuner intended. You can assign engine affinity and execution classes in such a way that task priority is not what you intended. You can also make assignments in such a way that tasks with low priority might not ever run, or might wait for extremely long times – another reason to plan and test thoroughly when assigning execution classes and engine affinity.
