Cheers,
Naren
(OCEEJBD6, SCWCD5, SCDJWS, SCJP1.4 and Oracle SQL 1Z0-051)
Naren Chivukula wrote:Hi TirupathiRao,
I don't think that's a good design practice. You'll end up writing extra code to deal with threading mechanism, assembling response and fault handling. What issues do you have in getting all the 100 records in one go?Unless you show all the records in a web page or to process at a time, you can look up for smaller chunks like 20 at a time.
Everything has got its own deadline including one's EGO!
[CodeBarn] [Java Concepts-easily] [Corey's articles] [SCJP-SUN] [Servlet Examples] [Java Beginners FAQ] [Sun-Java Tutorials] [Java Coding Guidelines]
Cheers,
Naren
(OCEEJBD6, SCWCD5, SCDJWS, SCJP1.4 and Oracle SQL 1Z0-051)
Naren Chivukula wrote:Hi TirupathiRao,
Thread are usually applied to perform parallel activities of slightly different in behaviour. For example, on a browser user can scroll and at the same time load an applet or call two different web services at the same time and consolidate their responses. If you are planning to use threads for this particular purpose, you'll end up waiting for other threads to complete and join all the threads and eventually construct different thread out comes into a single response. Did you check if you could do all the records in one go? I suspect you would get memory related problems and more likely if your design/coding is not well done.
Cheers,
Naren
(OCEEJBD6, SCWCD5, SCDJWS, SCJP1.4 and Oracle SQL 1Z0-051)
Naren Chivukula wrote:Okay, if you really want to go with that approach knowing downs, it's up to you. I'd rather call sequentially in a for loop as it would not make any difference because you are calling the same web service.
So, what problems are you facing in implementing that? Isn't that straightforward to implement? All you have to do is to create threads and invoke web service.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |