Escribe un solo trabajo. Haz que se ejecute regularmente.
Efectivamente, estará haciendo algo de la naturaleza de:
SELECT count(*) FROM table WHERE new = 1;
(o lo que sea)
Ejecuta eso cada segundo, 5 segundos, 10 segundos, lo que parezca razonable según tu actividad.
Cuando cuente ==N, ejecute su proceso. Cuando "tiempo desde la última ejecución" ==5 minutos, ejecute su proceso.
El proceso es el mismo, simplemente lo revisa más a menudo con los dos criterios.
Esto ofrece la ventaja de que no obtendrá una condición de carrera deshonesta en la que el trabajo se activa DOS VECES (porque el Trabajo A encontró el recuento de inserciones que casualmente fue de 5 minutos desde que se ejecutó el último trabajo). Raro, sí, pero las condiciones de carrera siempre parecen buscar activamente eventos "raros" que "nunca suceden".
En cuanto a la programación, un crontab es fácil porque no tiene que mantener su proceso, mantenerlo vivo, demonizar, etc. etc.
Si ya está ejecutando en un contenedor de ejecución prolongada (servidor de aplicaciones, tomcat, etc.), entonces ese problema ya está resuelto y puede aprovecharlo.
La desventaja de cron es su granularidad, solo se ejecuta como máximo cada minuto. Si es demasiado tiempo, no funcionará para usted. Pero si está bien, entonces tiene un valor real tener un proceso simple que simplemente se encienda, verifique y se cierre. Por supuesto, tendrá que conservar su estado de alguna manera (podría buscar en un registro de trabajo para ver cuándo se ejecutó el último trabajo, por ejemplo).
Dentro de Java, hay muchas opciones:subprocesos sin procesar, dormir, temporizadores, ScheduledExecutorService, algo como Quartz, EJB Timer beans (si está ejecutando un contenedor Java EE).
Pero, soy un fan de KISS. Si un trabajo cron puede hacerlo, déjalo y hazlo una vez.
