3 ms·

This is an interesting space. I think it is interesting that job scheduling, dependency graphs, dirty refresh logic, mutually exclusive execution are all relev

This is an interesting space. I think it is interesting that job scheduling, dependency graphs, dirty refresh logic, mutually exclusive execution are all relevant in the same space. I recently working on some Java code to schedule mutually exclusively across threads. I wanted to schedule A if B is not running and then A if B is not running. Then alternately run the two. I think it's traditionally solved with a lock in distributed systems. I think there is inspiration from GUI update logic too and potential for cache invalidation or cache refresh logic in background job processing systems. How does JobRunr persist jobs? If I schedule a background job from an inflight request handler, does the job get persisted if there is a crash?

manyxcxi 3y ago
It does. Primarily, worker threads query the DB for jobs to pick up. They can write state back when running a job, and they can have configurable (per job type) retry rules. So in your case, the crash would likely leave it in an open/running state if it was already picked up, at which point timeout/retry rules would kick in after a restart. If the job wasn’t running yet, just queued, then it would be business as usual upon restart.