Its main features are:

Supports both simple recurring jobs and ad-hoc jobs scheduled at runtime.

and scheduled at runtime. Cluster-friendly. Optimistic locking is used to ensure execution by a single node in the cluster.

Optimistic locking is used to ensure execution by a single node in the cluster. Persistent. A single database table is used for the scheduled instances of jobs.

A single database table is used for the scheduled instances of jobs. Simple and embeddable, meant to be embedded in an existing application. Has a single dependency on slf4j.

So, let’s look at some examples. And to avoid confusion, a job in db-scheduler is called a task, and a scheduled instance of a task is called an execution.

Setting up a scheduler with a recurring task is simple. First we set up a Task-class with an hourly schedule:

A RecurringTask is rescheduled according to its Schedule after every execution

Then we create and start a scheduler instance, instructing it to schedule the recurring task:

After every execution, the task’s schedule will be consulted to decide the next execution-time.

The other type of common tasks are ad-hoc tasks, which is scheduled at runtime and typically only have a single future execution. State relevant to the execution can be stored with the execution (for a full example, see github):

A OneTimeTask has a single execution

… and that’s basically it. Some more examples can be found on github, along with documentation on its inner workings.

If you try it out and feel some feature is missing, don’t hesitate to add a feature request on Github :)