4 ms·
> So, it's unbelievable how no such solution existed before I think a lot of folks solved this problem at the application level using background workers or job
by nickjj 5y ago
> So, it's unbelievable how no such solution existed before
I think a lot of folks solved this problem at the application level using background workers or job processing services.
For example, Celery with Python or Sidekiq with Ruby has had recurring job support for a really long time. Celery supported this since 2010. You could run distributed jobs (recurring or not) this way without using cron directly or requiring a custom DB extension.
IMO it feels much more natural to solve this problem at the app level with a background worker since you can run any task you want, not just DB queries. This also has the added benefit of letting you use your DB library of choice (ORM, etc.) since you can run any code you want within the job.
- mey 5y agoIn the Java world the venerable (pre-2006) Quartz library has been around a long time, and is certainly not the only solution. https://www.quartz-scheduler.org/overview/ https://www.quartz-scheduler.org/overview/
- luhn 5y agoAlthough Celery itself is distributed, the cron manager (celery-beat) is not and will not coordinate with other nodes. If you have two nodes running celery-beat, you'll get two jobs dispatched every time a cron triggers. imo defeats the whole purpose, at that point I might as well use crontab.