Enum ExecutionLimitScope

Namespace

Quartz

Assembly

Quartz.dll

What an execution limit is counted against.

public enum ExecutionLimitScope

Fields

Cluster = 1

The limit is what every node sharing the job store may run between them.

The count comes from the store, not from any node's memory: for the ADO.NET store it is the QRTZ_FIRED_TRIGGERS rows, which already hold both reservations and running executions and are already cleaned up when a node dies. That makes the ceiling fail closed — a node that cannot reach the store cannot acquire anything either — but also approximate: the default acquisition path takes no cluster lock, so two nodes can read the same remaining count and each take from it. The overshoot is bounded by the nodes acquiring at that instant, and setting AcquireTriggersWithinLock removes it at the cost of serializing acquisition.

A store whose Clustered is false has one node, so a cluster-scoped limit and a node-scoped one are the same number there.

Node = 0

The limit is what this node may run concurrently. Every node enforces its own copy, so an N-node cluster can be running N times the number. This is the default, and it is what execution limits have always meant.

Remarks

The two are not alternatives to each other and one set of limits may use both. A node-scoped limit describes what this machine can stand — the reason a batch node and an API node in the same cluster declare different numbers. A cluster-scoped limit describes a quota — the reason a tenant may run eight jobs at a time no matter how many nodes are up.