Spring Scheduling: @Scheduled vs Quartz

Question

I'm reading the Spring 3.0 docs regarding scheduling. I'm leaning towards Spring's JobDetailBean for Quartz. However, the @Scheduled annotation has captured my eye. It appears this is another way of scheduling task using the Spring Framework. Based on the docs, Spring provides three way of scheduling:

1. @Scheduled
2. Via Quartz
3. Via JDK Timer

I have no interest in the JDK Timer. Why should I choose @Scheduled over Quartz? (When I mention Quartz I mean using Spring's bean wrapper for Quartz).

Let's say my use case is complex enough that I will be communicating to a third-party web service to import and export data at specified intervals.

Answer 1

Quartz is an order of magnitude more complex than Spring's built in scheduler, including support for persistent, transactional and distributed jobs. It's a bit of a pig, though, even with Spring's API support.

If all you need to is to execute methods on a bean every X seconds, or on a cron schedule, then @Scheduled (or the various options in Spring's <task> config schema) is probably enough

Answer 2

I have to state my own experience regarding use of @Scheduled versus Quartz as scheduling implementation in a Spring application.

Scheduling jobs had the following requirements:

• End users should have the ability to save and schedule (define execution time) their own tasks
• Scheduled jobs during server downtime should not get omitted from jobs queue

Hence, we have to try and use Quartz implementation (version 2.2.3) in order to support persistence of jobs in a database. Some basic conclusions are the following:

• Integration with a Spring 4 MVC application is not difficult at all using quartz.properties file.
• We had the ability to choose a second database for storing the jobs from the main database.
• Jobs scheduled during server downtime begin running as long as server comes up.
• As a bonus we managed to maintain in main database some useful (and more user-oriented) information about user defined scheduled jobs using custom JobListener and TriggerListener.
• Quartz is a very helpful library in applications with more complex scheduling requirements.

Answer 3

According to Quartz Documentation, we can use some more complex features that don't exist in @Scheduler. For example:

1. in Quartz we can place a scheduler in stand-by mode with scheduler.standby(); and re schedule it with scheduler.start();.
2. shutting down a scheduler before the execution of the job or after that with scheduler.shutdown(true); and scheduler.shutdown(false);
3. storing a job for later use and when you need the job you can triggered it.

JobDetail job1 =newJob(MyJobClass.class).
withIdentity("job1","group1").
storeDurably().
build();

4. Add the new job to the scheduler, instructing it to "replace" the existing job with the given name and group (if any).

JobDetail job1 = newJob(MyJobClass.class).
withIdentity("job1", "group1").
build();

Answer 4

In Spring you could schedule task by using FixedRate,FixedDelay and cron. But most of the scheduled job requires dynamic handling of execution time. So in this scenario it is better to use Quartz as it provide the option to store scheduled jobs in DBJobstore as well as RAMJobstore.

Answer 5

Spring provides an easy way to implement API for scheduling jobs. It works great until we deploy multiple instances of our application.

Spring, by default, cannot handle scheduler synchronization over multiple instances. It executes the jobs simultaneously on every node instead.

You can look at ShedLock — a Java library that makes sure our scheduled tasks run only once at the same time and is an alternative to Quartz.