Écrivez un seul travail. Faites-le exécuter régulièrement.
En fait, vous ferez quelque chose du genre :
SELECT count(*) FROM table WHERE new = 1;
(ou autre)
Exécutez cela toutes les secondes, 5 secondes, 10 secondes, tout ce qui semble raisonnable en fonction de votre activité.
Lorsque count ==N, exécutez votre processus. Lorsque "temps depuis la dernière exécution" ==5 minutes, exécutez votre processus.
Le processus est le même, il suffit de le vérifier plus souvent avec les deux critères.
Cela offre l'avantage que vous n'obtiendrez pas de condition de concurrence indésirable où le travail se déclenche DEUX FOIS (parce que le travail A a trouvé le nombre d'insertions qui se trouve être à 5 minutes de l'exécution du dernier travail). Rare, oui, mais les conditions de course semblent toujours rechercher activement des événements "rares" qui "n'arrivent jamais".
Quant à la planification, une crontab est facile car vous n'avez pas à maintenir votre processus, le maintenir en vie, le démoniser, etc. etc.
Si vous utilisez déjà un conteneur de longue durée (serveur d'applications, tomcat, etc.), ce problème est déjà résolu et vous pouvez simplement en tirer parti.
L'inconvénient de cron est sa granularité, il ne s'exécute qu'au maximum toutes les minutes. Si c'est trop long, ça ne marchera pas pour vous. Mais si tout va bien, alors il y a une réelle valeur à avoir un processus simple qui s'allume, vérifie et s'arrête. Bien sûr, il devra conserver son état d'une manière ou d'une autre (il pourrait consulter un journal de travail pour voir quand le dernier travail a été exécuté, par exemple).
Dans Java, il existe de nombreuses options :threads bruts, sommeil, minuteries, ScheduledExecutorService, quelque chose comme Quartz, EJB Timer beans (si vous exécutez un conteneur Java EE).
Mais, je suis un fan de KISS. Si une tâche cron peut le faire, laissez-la et faites-la une fois.
