Four fixes for the 3.x line, all additive: no public API change and no schema change. They are ports of fixes found while building Quartz.NET 4.3, plus one found while proving them.
Fixed
- A trigger no longer fires after
Standby()has returned. The scheduler's loop checked whether it was paused before draining its wake-up signal, so aStandby()that landed between the two, most likely while the loop was waiting for a free worker on a busy scheduler, was lost. The round then went on to fire a trigger due within the nextIdleWaitTime(30 s by default). (#3908) - A trigger scheduled just after another is no longer passed over, and one held in standby is let go. When two schedule calls landed before the loop read the first, the later one's time overwrote the earlier, more urgent one. That trigger then ran up to
IdleWaitTimelate, or went through misfire handling. The same overwrite meantStandby()followed byScheduleJob()could fire a trigger the loop was holding. (#3908) - A row-lock semaphore no longer acts on a transaction SQL Server has ended. When SQL Server aborted a transaction contending for the lock row, the semaphore retried its lock statement inside the dead transaction: error 41302 with memory-optimized locks, or a 1205 deadlock victim. SqlClient ran the retry outside any transaction, so the store acted without holding
TRIGGER_ACCESS.UpdateLockRowSemaphore,UpdateLockRowSemaphoreMOTandStdRowLockSemaphorenow give up, andJobStoreSupportretries the operation in a fresh transaction. (#3908) DirectSchedulerFactory.CreateSchedulerreturns a scheduler whose job store has finished initializing. It started the store'sInitializewithout waiting for it. A call made beforeStart()could then run while the store was still probing its optional columns, and fail reading a trigger (IndexOutOfRangeException: MISFIRE_ORIG_FIRE_TIME). A store that fails to initialize now failsCreateSchedulerinstead of leaving a broken scheduler registered. (#3908)
Full Changelog: v3.22.0...v3.22.1