Skip to content

Fire on acquire: already-due triggers are acquired and fired in one transaction #3864

Description

@lahma

Conditional: ship in 4.3 only if P1 + P2 measure below 220 firings/s on S2 at defaults; otherwise 4.4.

Change. New IJobStore DIM ValueTask<TriggerAcquisitionResult> AcquireNextTriggersAndFireDue(TriggerAcquisitionRequest request, CancellationToken cancellationToken = default), TriggerAcquisitionResult { List<TriggerFiredResult> Fired; List<IOperableTrigger> Pending; }. Default body = AcquireNextTriggers then TriggersFired on the subset with NextFireTimeUtc <= now, so custom stores and both forwarders keep working (DelegatingForwardingTest must see the declaration; a NEW name, not an overload, because of the per-name DIM marker). ADO: candidates, trigger read, one SelectJobs(keys) per batch (new delegate DIM), CAS claim, the fired row inserted directly as EXECUTING with the job named (one INSERT replaces INSERT + UPDATE), ApplyTriggerFired's batch — all in one transaction, locked as today when MaxCount > 1. The loop (QuartzSchedulerThread.cs:367-385) dispatches Fired immediately and treats Pending as today's triggers. RAMJobStore: a native one-lock version.

Per firing at batch ≈ 5: 16.6 / 2.8 → ~13.2 statements / 2.4 commits. Expected 300–400/s with P1 + P2. Mixed cluster: the EXECUTING-with-job fired row is the shape a 4.2 fire produces itself (IsJobCurrentlyExecuting and ClusterRecover, Cluster.cs:551-586, read it). Risk medium-high (loop + public surface). ~6 days.

Part of #3860.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions