Jay Roy
asked on
fork-join implimentation
hi guys
I have some executor service code which i want to re-write using fork-join. I am looking for better scalability.
ExecutorService executor = Executors.newFixedThreadPo ol(3);
final HSSFWorkbook runnableWb = wb;
Runnable expTask = new Runnable(){
public void run(){
getExportDocumentObject(tr ue, "Excel",buffer, mReq,runnableWb);
}
executor.submit(expTask);
shutdownAndAwaitTerminatio n(executor );
How do i rewrite the above code snippet using fork join API?
thanks
I have some executor service code which i want to re-write using fork-join. I am looking for better scalability.
ExecutorService executor = Executors.newFixedThreadPo
final HSSFWorkbook runnableWb = wb;
Runnable expTask = new Runnable(){
public void run(){
getExportDocumentObject(tr
}
executor.submit(expTask);
shutdownAndAwaitTerminatio
How do i rewrite the above code snippet using fork join API?
thanks
As explained in this Java Tutorial, the actual code that does the work needs to be explicitly coded to work with the Fork/Join API. It's not something where you can just submit your method that does the work to a different API and you somehow magically get better scalability, multithreaded code. You need to actually think about your problem and what the code (within that getExportDocumentObject method) is doing and work out a) if there are benefits of doing multi-threading and if so, b) actually changing that code to do be able to be run in a multi-threaded way.
As I asked in another of your questions on this stuff, what is actually happening within that method, eg. database access, filesystem acces, CPU intensive algorithms, etc? Also, you claim that you are after better scalability; what have you done to determine that the current situation is not good enough? As I also said in a different question, the app server will already be servicing your requests in a multi-threaded way, and so it is likely that you will already have a reasonably scalable solution already.
As I asked in another of your questions on this stuff, what is actually happening within that method, eg. database access, filesystem acces, CPU intensive algorithms, etc? Also, you claim that you are after better scalability; what have you done to determine that the current situation is not good enough? As I also said in a different question, the app server will already be servicing your requests in a multi-threaded way, and so it is likely that you will already have a reasonably scalable solution already.
ASKER
>>>As I asked in another of your questions on this stuff, what is actually happening within that method
well, the code i posted is just an example. It could be any code. I want to learn how to use fork-join implimentation and the benefits of using it.
well, the code i posted is just an example. It could be any code. I want to learn how to use fork-join implimentation and the benefits of using it.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER