Also, there are: 1. Windows Service keeping Quartz.net scheduler running 2. ASP.NET MVC Web app that acts like an admin dashboard which allows setting the schedule.
They both shares the same SQLite database with Quartz.net tables.
As I change the schedule using the second app (web app), the Windows Service catches these changes and follows the schedule that was just set.
I thought I should notify the first app somehow that the schedule change was made and it should be reloaded (by pausing jobs and starting them again or in some other way). But it turned out the Windows Service app loads these changes and there is no need for any other work.
My questions are:
How reliable is this construction?
Should I just let it work as it's now or I should create my own schedule settings reloading mechanism?
Luckily Quartz.Net is open source on GitHub.
If we take a look at the Run() method in the QuartzSchedulerThread we can see that whenever a thread becomes available, the JobStore is asked to AcquireNextTriggers().
Here we can see the driver delegate (which in your case is the StdAdoDelegate) is asked to SelectTriggerToAcquire().
That method directly accesses your SQLLite job store, so to answer your two questions:
This construction is very reliable because it is repeatedly and directly queried by the main scheduler.
You should arguably just let it work as it is now.
- 2 reads