Menu
Message queues are primarily used for executing asynchronous tasks on the server & I recently read about the Executor framework which also does the same thing spawns & manages threads to execute asynchronous tasks. Can anyone tell me the difference between the two?
534
The Executor Framework contains a bunch of components that are used to efficiently manage multiple threads. It was released with the JDK 5 which is used to run the Runnable objects without creating new threads every time and also mostly re-using the already created threads.
Executor just executes stuff you give it. ExecutorService adds startup, shutdown, and the ability to wait for and look at the status of jobs you've submitted for execution on top of Executor (which it extends). This is a perfect answer, short and clear.
A Thread represents something which is responsible for executing your code in parallel, while an Executor is an abstraction for concurrent task execution.
1) The submit() can accept both Runnable and Callable tasks but execute() can only accept the Runnable task. 2) The submit() method is declared in the ExecutorService interface while the execute() method is declared in the Executor interface.
The primary difference is that the Executor framework is for intra-program task queueing and execution, whereas JMS is for queuing between different programs (typically) on different machines.
Other differences include:
JMS queues are (or can be) persistent, where as Executor, etcetera are in-memory only.
JMS queues can (I believe) be used in a transactional system, where as Executor, etcetera can't. (In part, that is a consequence of the persistent / non-persistent distinction.)
So that means if my app is not distributed I can use Executor framework.
Maybe ...
For an instance I want to code a fb style notification system & publish subscribe will the use of executor framework be fitting for that? I assume the code will be on the same machine in a single db.
Well the problem is that the standard implementations of the Executor framework don't put the task queues into a database. They are just light-weight in-memory data structures. They don't persist if your application is restarted.
Now, I suppose you could write your Executor / ExecutorService class that put the queue into a database. But why bother? It would be simpler to use JMS or similar ...
117
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
