Spring Scheduling: @Scheduled vs Quartz

Solution 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

Solution 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.

Solution 3:

According to Quartz Documentation

We can use some more and complex feature that it doesn't exist in @Scheduler. for example:

1. in Quartz we can placing a scheduler in stand-by mode with scheduler.standby(); and re schedule it with scheduler.start();.
2. shutting down a scheduler before execution of 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();