Scrivi un singolo lavoro. Fallo eseguire regolarmente.
In effetti, farai qualcosa della natura di:
SELECT count(*) FROM table WHERE new = 1;
(o altro)
Eseguilo ogni secondo, 5 secondi, 10 secondi, qualunque cosa ti sembri ragionevole in base alla tua attività.
Quando count ==N, esegui il tuo processo. Quando "tempo trascorso dall'ultima esecuzione" ==5 minuti, esegui il processo.
Il procedimento è lo stesso, basta che tu lo controlli più spesso con i due criteri.
Ciò offre il vantaggio di non ottenere condizioni di gara canaglia in cui il lavoro viene attivato DUE VOLTE (perché il lavoro A ha rilevato il conteggio degli inserti che, proprio così, è stato di 5 minuti da quando è stato eseguito l'ultimo lavoro). Raro, sì, ma le condizioni di razza sembrano sempre cercare attivamente eventi "rari" che "non accadono mai".
Per quanto riguarda la pianificazione, un crontab è facile perché non devi mantenere il tuo processo, mantenerlo vivo, demonizzare, ecc. ecc.
Se stai già eseguendo in un contenitore di lunga durata (server app, Tomcat, ecc.), allora quel problema è già risolto e puoi semplicemente sfruttarlo.
Lo svantaggio di cron è la sua granularità, funziona solo al massimo ogni minuto. Se è troppo lungo, non funzionerà per te. Ma se va bene, allora ha un valore reale nell'avere un processo semplice che si accende, controlla e si chiude. Ovviamente, dovrà mantenere il suo stato in qualche modo (potrebbe cercare in un registro dei lavori per vedere quando è stato eseguito l'ultimo lavoro, ad esempio).
All'interno di Java, ci sono molte opzioni:thread non elaborati, Sleep, Timers, ScheduledExecutorService, qualcosa come Quartz, Bean Timer EJB (se stai eseguendo un container Java EE).
Ma io sono un fan dei KISS. Se un lavoro cron può farlo, lascialo e fallo una volta.
