Quartz job Vs. Thread for immediate one time task
Asked Answered
L

4

9

Let's say I have some unit of work that needs to get done and I want to do it asynchronously relative to the rest of my application because it can take a long time e.g. 10 seconds to 2 minutes. To accomplish this I'm considering two options:

  1. Schedule a Quartz job with a simple trigger set to fire only once and as soon as possible.
  2. Create a Runnable instance, hand it off to a Thread, and call run();.

In the context of the above I have the following questions:

  1. What does using the Quartz job get me that the thread doesn't have?
  2. What does using the runable get me that using the quartz job doesn't?
  3. In terms of best practices, what criteria ought be used for deciding between Quartz jobs and runnables for this use case?
Linguistics answered 29/8, 2014 at 16:0 Comment(0)
A
5

With Quartz you have many features "well implemented", like:

  • transaction mgmt of job execution
  • job persistence, so that we know the status of the running jobs
  • clustering supports
  • scheduling control, even if you just need the simple trigger. But it provides the possibility.

without using it, you have to control them on your own, some issue could be complicated.

Starting new thread:

  • light weight no job persistence, quartz api etc.
  • your application runs without extra dependency (quartz)
  • error source (from quartz) was reduced

It depends on what kind of job do you want to start, and if other features of your application require job scheduling too.

If your concern is just asynchronisation, you can just start a thread. If there were other concerns, like clustering, you may consider to use quartz.

Amathist answered 29/8, 2014 at 16:18 Comment(2)
Hi Kent, can you explain more about the clustering benefits of quartz? Is it just that quartz can strategically pick/balance which node to run a job on? or is there more to it than that? Also, what do you mean by transaction mgmt of job execution? I know that quartz reads and writes from it's own tables are transnational.Linguistics
quartz persists the job e.g. in database, if your application runs in a cluster env, quartz ensures that the job starts only once among all cluster instances. without quartz, you have to implement those locking/unlocking stuff by yourself. Quartz can join in jta transaction of application server (CMT)Amathist
H
2

I would not add Quartz to a project just for this capability, but if I already had Quartz installed and was already using it, then, yea, even for a one off I would use a one time immediate Quartz job.

The reason is simply consistency. Quartz already manages all of the details of the thread and job process. A single thread is Simple, but we also know from experience that even a single thread can be Not Simple.

Quartz wraps the thread in to a high level concept (the Job), and all that which it brings with it.

From a code base point of view you get the consistency of all your jobs having the same semantics, your developers don't have to "shift gears" "just for a thread". Later, they may "just do a thread" and run in to a complexity that Quartz manages painlessly.

The overhead of the abstraction and conditions that make a Quartz job are not significant enough to just use a thread in this case because "it's lighter weight".

Consistency and commonality are important aspects to a codebase. I would stick to the single abstraction and leverage as much as I can.

Hypoblast answered 29/8, 2014 at 16:27 Comment(0)
D
0

If it's a one-time job and there are no additional requirements, like job persistency, scheduling, etc. then you're better off with regular threads.

  1. Quartz jobs are much more robust than regular threads and support scheduling, job persistence, etc., all the other stuff that you probably don't need.
  2. No need to set anything up with Runnables and Threads
  3. If you think there might be more jobs that this, scheduled jobs, delayed jobs, etc, you have 2 options: go with Java's standard Excecutors. Set up a thread pool and use this to run your jobs. You might also want to use Spring's TaskExecutor abstraction so you can easily switch between Quartz and Executors when you need it. But that seems like an overkill for a one-time gig.
Deaconry answered 29/8, 2014 at 16:17 Comment(0)
T
0

For immediate 1 time task, Threads will be enough. But there are better plugins available like quartz, Spring Scheduler

Tweeze answered 29/8, 2014 at 18:26 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.