Acutally, I'm not sure why Ulf thinks that Thread.sleep is worse than the other alternatives. In cases I'm familiar with, they all end up using the same OS-level timer services regardless.
However, Thread.sleep
is an imprecise mechanism, and simply puts the thread to sleep for the indicated period of time. Since it also takes time to do the work and setup a new sleep, that means that it shouldn't be used where you want an event to fire at an exact time. But it's OK for informal polling intervals.
On the other end of the spectrum, there's the Quartz Scheduler. It can be used to create very elaborate schedules, including taking time off for weekends and holidays, adding extra events for peak times, and so forth. It also can manage multiple types of scheduled events, and uses thread pooling so instead of requiring as many threads as there are event types, you only allocate as many threads as are expected to be executing concurrently.
On a completely different track...
I've gone on record that I'm not a big fan of putting logic inside the database server. I've seen that turn out badly too often. However, when you start talking about watching table changes, the first
word that pops into my head is "trigger". Since you want Java code to respond to these changes, that may not be possible, but some databases also allow embedded Java procedures if that's a workable solution and your datacenter staff/DBA can deal with stuff like that.
You might also be able to code up a trigger that sends a message - perhaps an HTTP REST or Web Services request, and have the Java code get fired in response to that. If your changes are infrequent and irregular, that would be less overhead than polling.
