Java Multithreading : A Practical Scenario Implementation Guide

JAVA’s multithreading feature is always briefed about in the introduction of JAVA. The typical tutorials on thread creation process and the all famous bank withdrawal example offer little about a practical approach to problem solving using multithreading. In this post, I will brief about a problem I faced in one of my projects and applied multithreading to solve it. Before I proceed, I agree and appreciate your thoughts that the problem could have been solved in another way. I am highlighting what I applied and looked best to solve my problem.

Problem Statement:

  1. It’s a J2EE application consisting of Struts-Spring-JDBC.
  2. There is a screen that displays data about an entity. Data comprises of varied sources (5 to 6).
  3. For each source, there is a stored procedure that fetches data from the database.
  4. Stored procedures are independent.
  5. An initial setup was giving satisfactory response times.
  6. As the DB and processes grew in the system, the load on DB increased.
  7. Stored procedure started responding slowly due to heavy load on the system.
  8. Queries were optimized but response time remained high.

Solution: Split the requests in parts and process in parallel.

  1. Get a single request to the Struts action.
  2. Create multiple threads.
  3. Process the stored procedures independently in parallel.

Considerations:

  1. Load: Decide the number of threads you want to process in parallel. It should not be too high that it impacts other processes at the DB end.
  2. Return After All Complete: As per the current implementation; the user sees all data at once. Hence, the struts action must return to screen after all stored procedures have completed. This will prevent extra changes.

Implementation: Demonstrating with 2 threads parallel processing.

  1. Create a class that implement Runnable interface. I could not extend Thread class as I had to extend another project specific class.
  2. This will call the DB service that calls stored procedure.
  3. Rest all is grey matter for this post as its project and framework specific implementation of how to process DB request and responses.
  4. Next, create threads objects for class created in pointer#1.
  5. Start the threads.
  6. Join each of the created thread with the struts action thread.
  7. This will ensure that the struts action thread will not execute further till all parallel processing threads have completed.
  8. Note: The response time of screen will be difference of start time for first stored procedure to the end time of last stored procedure.
  9. A better approach can be AJAX implementation to show results as particular request completes.

Code Sample: Since I implemented this solution at my workplace; I cannot share the source. But I have created a demonstration sample at my github repository. The code comments are self-explanatory. Please refer to classes ThreadJoinCore & WorkerThreadOne.

@Facebook

Subscribe to Blog via Email

Quick Enquiry

2 thoughts on “Java Multithreading : A Practical Scenario Implementation Guide

  1. I have going to implement similar changes in my company, the headache of my situation is in the store procedure/ function have update the same table (it might have same row record but different column). I hope that you have any others advice or better solution for record lock issues ? Hope you can reply. Thanks in advance.

    • Hi,

      I haven’t come across a situation where i code to handle this scenario.
      Your situation will be tricky to handle but the core thing remains same:

      1. The transactions must be atomic; ensure only one thread updates a row at a time.
      2. There are some databases that can handle this by implementing locks.
      3. You need to handle dirty reads considering there are more than 1 threads running in parallel and targeting to update the same row.

      I would also suggest you to post it across in Java Ranch forum. It will be addressed by a wider audience.
      All the best.

Leave a Reply

Your email address will not be published. Required fields are marked *