aspose file tools*
The moose likes Threads and Synchronization and the fly likes 2 Different Implementations for a Long Running Job Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "2 Different Implementations for a Long Running Job" Watch "2 Different Implementations for a Long Running Job" New topic
Author

2 Different Implementations for a Long Running Job

ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

We have a system which receives some input data (say in the form of files or a db update) from external sources. We have a job which wakes up periodically, checks for the presence of new data and then does some parsing/data manipulation. I have posted it below and for the sake of brevity and conciseness kept it simple.



So far so good.

We have 2 options to implement this

Option 1
-----------

Create a thread on startup, the thread checks for presence of input data and creates a Work object to process the job.



Option 2
-----------

Have a controller class that checks for the condition, when it is met create a Thread that does the work


The thread does the job and comes out (see below)



The difference between the two is that while the first creates a long running thread, in option(2) a thread is created on demand.

Both would work and work correctly. What I would like to hear from all the good and experienced people here is if the options presented above just a programmer's prefence or is one option better than the other (performance, memory considerations) etc?

Thanks for your patience in reading this post.

cheers,
ram.
Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

Look into the java.util.concurrent package. There you'll find classes that can be used for these situations and make it easy to switch from a single threaded approach to a multi threaded approach.


"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
R van Vliet
Ranch Hand

Joined: Nov 10, 2007
Posts: 144
As mentioned, every time you find yourself typing "extends Thread" you can probably do the same thing better using the java.util.concurrent package. Not always, but usually. And by the way, it's generally accepted as preferable to implement Runnable and pass an instance of such a Runnable to a new or pooled thread rather than extend the Thread class in the first place. This has many advantages (Google it).

So with that mind moving on to my answer of your actual question ;)

I personally think it is preferred to seperate the work itself from the component that needs to decide if work needs to be done in the first place. This'll allow you to, for example, define different kinds of work in different classes while using the same controller class to trigger the work (that's another reason to use Runnable, you can pass different units of work to the same thread instance over and over if desired).


ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

I understand the benefits of the concurrent package.

>I personally think it is preferred to seperate the work itself from the component that needs to decide if work needs to be done in the first place. This'll allow you to, for example, define different kinds of work in different classes while using the same controller class to trigger the work (that's another reason to use Runnable, you can pass different units of work to the same thread instance over and over if desired).

I was looking for some thing on those lines - Thank you for that

ram.
R van Vliet
Ranch Hand

Joined: Nov 10, 2007
Posts: 144
ramprasad madathil wrote:I understand the benefits of the concurrent package.

>I personally think it is preferred to seperate the work itself from the component that needs to decide if work needs to be done in the first place. This'll allow you to, for example, define different kinds of work in different classes while using the same controller class to trigger the work (that's another reason to use Runnable, you can pass different units of work to the same thread instance over and over if desired).

I was looking for some thing on those lines - Thank you for that

ram.


You're very welcome, ThreadPoolExecutor + Runnable will give you exactly what you need
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: 2 Different Implementations for a Long Running Job
 
Similar Threads
Interrupt Confusion
Threads and Synchronization examples
Clarification wanted: Extending Threads vs. Implementing Runnable
Thread Communication using wait() and notify()
best way to kill ?