Napisz jedną pracę. Niech uruchamia się regularnie.
W efekcie będziesz robić coś w rodzaju:
SELECT count(*) FROM table WHERE new = 1;
(lub cokolwiek)
Uruchamiaj to co sekundę, 5 sekund, 10 sekund, cokolwiek wydaje się rozsądne na podstawie Twojej aktywności.
Gdy liczba ==N, uruchom swój proces. Gdy „czas od ostatniego uruchomienia” ==5 minut, uruchom proces.
Proces jest taki sam, po prostu sprawdzasz to częściej za pomocą dwóch kryteriów.
Daje to tę zaletę, że nie dostaniesz nieuczciwych warunków wyścigu, w których zadanie uruchamia się DWUKROTNIE (ponieważ Zadanie A znalazło liczbę wstawek, która tak się składa, że wynosiła 5 minut od ostatniego uruchomienia zadania). Rzadkie, tak, ale warunki wyścigowe zawsze wydają się aktywnie poszukiwać „rzadkich” wydarzeń, które „nigdy się nie zdarzają”.
Jeśli chodzi o planowanie, crontab jest łatwy, ponieważ nie musisz utrzymywać procesu, utrzymywać go przy życiu, demonizować itp. itd.
Jeśli już korzystasz z długo działającego kontenera (serwer aplikacji, tomcat itp.), ten problem został już rozwiązany i możesz to po prostu wykorzystać.
Wadą crona jest jego szczegółowość, działa tylko co najwyżej co minutę. Jeśli to za długo, to nie zadziała. Ale jeśli wszystko jest w porządku, to naprawdę warto mieć prosty proces, który po prostu się zapala, sprawdza i kończy. Oczywiście będzie musiał jakoś zachować swój stan (może na przykład zajrzeć do dziennika zadania, aby zobaczyć, kiedy ostatnie zadanie zostało uruchomione).
W javie jest wiele opcji:surowe wątki, uśpienie, Timery, ScheduledExecutorService, coś takiego jak Quartz, ziarna EJB Timer (jeśli używasz kontenera Java EE).
Ale jestem fanem KISS. Jeśli zadanie cron może to zrobić, pozwól na to i zrób to raz.
