This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Threads and Synchronization and the fly likes Help : Design of multi-threaded app Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Help : Design of multi-threaded app" Watch "Help : Design of multi-threaded app" New topic
Author

Help : Design of multi-threaded app

Jack Bercy
Greenhorn

Joined: Jul 31, 2004
Posts: 11
Hello,

Context : let's say I have multiple credit cards, and let's also say that I can access my balances and past transactions online, through the respective issuer's web sites.

I can easily build a uni-threaded application, with the use of Jakarta Commons HttpClient, that will login to each issuer's web site sequentially, and collect balance and transaction information. I'd basically create a class for each issuer, plus an interface with the "getBalance()" and "getPastTransactions()" method, and make each issuer-class implement the interface (each implementation would essentially parse the resulting HTML to extract whatever data I'm interested in). So, for N issuers, I'd have N classes, and one interface.

What if I wanted to make this application multi-threaded ?

For example, let's say that on my application's GUI, I have a button called "Update all balances". When clicked, this button would result in each of the issuer's "getBalance()" method being called. I'd like these calls to be multi-threaded. In other words, I don't want to have to wait for one issuer's getBalance() method to end before I can call the next issuer's getBalance() method.

From what I understand of multi-threading (in java), the only part of a class that is multi-threaded is its "run" method, if it implements Runnable.

How would you change my class design so that each method of each issuer could be multi-threadable ?

Thanks for your insight...
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Hi, first check out the Sun Concurrency Tutorial. Most all the Sun tutorials are pretty good.

In short, you will move all the code that does the work into the run() method of a class that implements Runnable, make an instance per site and a thread per instance.

Since you have a Swing application, you will need to write another Runnable to update the GUI. This time we give the Runnable to the SwingUtils instead of starting a new thread. So the runnable that does the http work looks like:

Does that makes sense? Run through the thread tutoria, maybe look up the Swing tutorial for details on the SwingUtilities. Let us know what you make!


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Jack Bercy
Greenhorn

Joined: Jul 31, 2004
Posts: 11
Originally posted by Stan James:



Do I still have one class per issuer ? I'm not sure I understand... In other words, could I have the following in the MyGetBalance class :



Thanks for your help...
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I'd expect one class for all issuers, but one instance per issuer. Each instance will get the info it needs about the issuer in the constructor or in setX() methods. But it will do all the work in the run() method.

The getBalance() method can do whatever it needs to get the data. The publishBalance() method can take any number of paths to get the balance back to the screen. I mentioned SwingUtilities before; that would do the job but might make this little class too tightly tied to the GUI for some tastes.

There are a couple other ways for the main thread to gather information back from the other threads it starts. We can dig into those if you like.
Jack Bercy
Greenhorn

Joined: Jul 31, 2004
Posts: 11
Originally posted by Stan James:
The getBalance() method can do whatever it needs to get the data.


This is where it's not clear for me. See, the algorithm to get the balance from issuer A will be very different from the algorithm to get the balance from issuer B. We're talking about HTML here, and as you can imagine, the process to get to the balance will be quite different depending on the issuer.

Am I to understand that the getBalance() method would need to test the "issuer" String, and react accordingly, as in :



From a practical standpoint, I would have hoped that if one issuer changes its web site, then I'd only need to modify THAT issuer's class, and not have to touch anything else...

Unless there's some way to create, in the getBalance() method, an object whose type is dependent on the "issuer" string passed into the constructor ? In OO Perl, you can have something like this :



By the way, thanks for your time Stan James, I really appreciate it.
[ December 14, 2006: Message edited by: Jacques CestJacques ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
the algorithm to get the balance from issuer A will be very different from the algorithm to get the balance from issuer B


Ah, that I missed or guessed wrong. So we might have something like:

This puts each different algorithm into its own class for the kind of separation you wanted. Each one implements getBalance() in a different way. You might have two issuers with the same strategy or not.

It would be best to avoid a lot of if-else statements to create the strategy for the issuer. I like to map keys to classnames in configuration:

Now we can add new issuers with new algorithms without touching the main thread or MyGetBalance. Does that sound fun?
[ December 15, 2006: Message edited by: Stan James ]
Ajay Saxena
Ranch Hand

Joined: Nov 13, 2006
Posts: 154
So basically, the solution is an implementation of a factory of runnable objects.

The problem is good indeed for biginners in Java and concurrency programming as it leads to a combination of Polymorphism (factory pattern here ) and concurrency.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Yup. I'd go with the factory even without threads. You could use the same mechanism to get a Strategy and run them one after another. That kind of polymorphism and factory combination is just one of my favorite tools; I probably overuse it as we are all tempted to do with favorites.
 
 
subject: Help : Design of multi-threaded app