Design issue with threads ...

Question

Hello,
I need your thoughts in how to proper use java threads in solving this issue:
* I have an application that query a database for a list of users, and for each row retrieved from the database as a result the application should process that user and send him an email.
Now the procdural approach for looping each user and send him an email at a time is not convinient as the number of users is big (20,000 users or more) so I thought of why not to use threads to send say every 300 user at a time (i.e, creating 300 threads), but the problem is that I cannot really figure how to manage those threads, to make sure that there are 300 threads are running all the time, and what if a thread was taking more time that the others ... etc.
So, is this approach is the right one, and can you guide more more for how to control the threads this way, if not what do you suggest?
Your guidance is highly appreciated,
tamer

Answer 1

I'm not sure that threads will help your cause. But they could. Let me explain:
Threads have several purposes. Two instantly spring to mind:
1. to make things faster.
2. to (make it seem like you) do two (or more things) at once.
First #2. This is often a usability issue. For example, a web server has to server multiple clients at the "same time". This is often done with threads - it gives the illusion that many concurrent users are supported. In reality the CPU/JVM is swapping beween the different requests. More CPUs allow for "realer" concurrency. Speed is only a by-product here.
Now #1: Make things faster. Threading works well for speed when the tasks being done differ.
For example, consider human multithreading: ask me to whistle for 5 seconds, and 5 seconds later I'll be done. Then ask me to scratch my head with both hands for 5 seconds, and 5 seconds later I'll be done. Total: 10 seconds. Ask me to do both at the same time. Result: 5 seconds later I'll have scratched my head and whistled for 5 seconds. 50% time saving.
However, ask me to touch type for 5 seconds, and scratch my head for 5 seconds, it'll take 10 seconds or more. If you ask me to do one, then the other, I can spend 5 seconds at one then the other - total 10 seconds. Ask me to do both concurrently, and I'll take more than 10 seconds, as I'll be moving my hands back and forth from the keyboard to my head, and vice-versa.
I have a feeling that running multiple threads in your case would be like asking you to scratch your head and scratch your head all at the same time. But this may not strictly hold true for several reasons:
1. your DB should scale, i.e. handle two simultaneous requests faster than two concurrent requests. However, this will probably not be true of 300 simultaneous requests being faster than 300 concurrent (or 50 * 6-concurrent requests).
2. if you are in a multi-CPU environment then some concurrentcy improvements would be expected (more hands for head scratching).
3. your application does two things: reads a DB and sends a mail. While sending one mail, you should be albe to concurrently read the next record. i.e. concurrency is supported here, as you don't have resource contention here.
So, you will probably get some benefit from threads. Adding too many will only slow you down, as there'll be too much time spend task switching, as you'll suffer resource contenion on the DB/mail server.
I suggest that you run your program with several configurations, i.e. number of threads, and see what one gives the best results. For fast results, I'd suggests trying the following number of threads:
1, 2, 4, 8, 16, 32, 64, 128, 256, ...
when things start to slow down, you know where to search for your optimum thread number. You could also do with profiling your application if speed is a very pressing issue.
Finally, one clarification: this is not OO. You could do multi-threading in a procedural environment.
Good luck.
if you are running on a multi-CPU environment, then the DB