I am currently evaluating various concurrency solutions to solve a business problem. The use case is akin to the “embarassingly-parallel” algorithim.
Basically for a single user request, we need to retrieve data from multiple different data sources before computing the response. Currently all 3 DAO calls are made serially but have no inter dependencies so can be made in parallel.
Solutions implemented so far:
- java.util.concurrent.ExecutorService using Callables and Futures
- org.springframework.scheduling.annotation.Async to enable spring manage the thread pool but sill allow me to make aysnchronous calls
- Akka (deemed overkill) for our relatively simple use case
Last framework I wanted to evaluate was Java ForkJoin framework, I can see multiple examples of use of RecursiveTasks, but my use case is not recursive in nature so doesnt fit the model:
if task is small enough
do it
else
split it and recursively call same method (i.e. divide and conquer)
My use case is, split task into 3 tasks. fork all 3 and join again. Is this even a valid use case for the ForkJoin implementation? Or should i stick with the generic ExecutorService implementation.
The advantage of an ExecutorService is that it can keep thread pool. So in your case, for multiple consecutive calls, the threads will be reused, which saves the OS some cycles to stop and create new threads.
The further advantage of the ForkJoinPool, is that it can ‘steal’ work. AFAIK, what it means is that it allows one thread that has finished a task to immediately execute another task with much less overhead than the ExecutorService.
In your case, the advantage of the ForkJoinPool seems minimal.