Quartz job Vs. Thread for immediate one time task

Question

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?

Answer 1

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.

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