Skriv ett enda jobb. Låt det köras regelbundet.
I praktiken kommer du att göra något av typen:
SELECT count(*) FROM table WHERE new = 1;
(eller vad som helst)
Kör det varje sekund, 5 sekunder, 10 sekunder, vad som än verkar rimligt baserat på din aktivitet.
När räkna ==N, kör din process. När "tid sedan senaste körning" ==5 minuter, kör din process.
Processen är densamma, du bara kontrollerar den oftare med de två kriterierna.
Detta ger en fördel att du inte kommer att få oseriösa race-tillstånd där jobbet avfyras TVÅ GÅNGER (eftersom jobb A hittade inserträkningen som bara-så-råkar ha varit 5 minuter från när det senaste jobbet körde). Sällsynt, ja, men tävlingsförhållanden verkar alltid aktivt söka efter "sällsynta" händelser som "aldrig händer".
När det gäller schemaläggning är en crontab lätt eftersom du inte behöver underhålla din process, hålla den vid liv, demonisera, etc. etc.
Om du redan kör i en långvarig behållare (appserver, tomcat, etc.) är det problemet redan löst och du kan bara utnyttja det.
Nackdelen med cron är dess granularitet, den körs bara högst varje minut. Om det är för länge kommer det inte att fungera för dig. Men om det är ok, så finns det ett verkligt värde i att ha en enkel process som bara lyser upp, kontrollerar den och avslutas. Naturligtvis måste det bestå sitt tillstånd på något sätt (det kan titta i en jobblogg för att se när det senaste jobbet kördes, till exempel).
Inom java finns det massor av alternativ:råa trådar, sovande, Timers, ScheduledExecutorService, något som Quartz, EJB Timer beans (om du kör en Java EE-behållare).
Men jag är ett KISS-fan. Om ett cron-jobb kan göra det, låt det och gör det en gång.