It's just prudent journalism to never, ever link to an article that's published on April 1st, no matter how interesting or authentic the content might be. But with a few days of sober second thought, it would appear that Tomasz Nurkiewicz isn't fooling around with regards to his discussion about working with Spring's JDBCJobStore and Terracotta's Quartz.
One of the things I like about this particular post is that it brings together two of the major stalwarts of TheServerSide over the years: Terracotta and Spring. In this case, it's Terracotta's Quartz Scheduler, and Spring's JDBC magic, two important aspects of both Spring and Terracotta, but at the same time, items that get overshadowed by Spring's dependency injection and Terracotta's Ehcache.
Here's a slice of Thomasz' tutorial pie:
In Quartz you essentially have a choice between storing jobs and triggers in memory and in a relation database ( Terracotta is a recent addition to the mix). I would say in 90% of the cases when you use RAMJobStore with Quartz you don't really need Quartz at all. Obviously this storage backend is transient and all your pending jobs and triggers are lost between restarts. If you are fine with that, much simpler and more lightweight solutions are available, including ScheduledExecutorService built into JDK and @Scheduled(cron="*/5 * * * * MON-FRI") in Spring. Can you justify using extra 0,5MiB JAR in this scenario?
This changes dramatically when you need clustering, fail-over, load-balancing and few other buzz-words. There are several use-cases for that:
In all cases above we need some sort of non-transient global storage to keep track which jobs were executed, so that they are run exactly ones by one machine. Relational database as a shared memory works good in this scenario.
- single server cannot handle required number of concurrent, long running jobs and the executions need to be split into several machines - but each task must be executed exactly ones
- we cannot afford to run jobs too late - if one server is down, another should run the job on time
- ...or less strictly - the job needs to run eventually - even if the one and only server was down for maintenance, delayed jobs need to be run as soon as possible after restart
Read the full article here: Configuring Quartz with JDBCJobStore in Spring