aspose file tools*
The moose likes Threads and Synchronization and the fly likes Who's using threads? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Who Watch "Who New topic
Author

Who's using threads?

Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Lasse you made my point: your solution is based only on JMS/MDB and not on threads management.
Ohh, I haven't seen the 2nd solution. Would you implement that solution? Me definitely not. And another thing? How do you establish the forced refresh interval for the wait page?

./pope
[ October 22, 2004: Message edited by: Ali Pope ]

blog - InfoQ.com
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Lasse,

I agree with you that a J2EE developer will not be writing any thread programming (except may be for some synchronized blocks). I have been writing threads for non-J2EE applications like for polling, data gathering, batch system.


Groovy
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ali Pope:
Ohh, I haven't seen the 2nd solution. Would you implement that solution? Me definitely not.
If I didn't have JMS (running on Tomcat, for example) then yes, I probably would.

Originally posted by Ali Pope:
How do you establish the forced refresh interval for the wait page?

Put this on the HTML page:
<META HTTP-EQUIV="Refresh" CONTENT="10;URL=http://www.foobar.com/PollForResults?job=122353251325352">


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Lasse, my question was not about how you make this technically, but rather how you compute the refresh time in order not to kill you servlet.

./pope
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Okay, the other part of my answer.

For fun, I'm working on a real time online multiplayer game. The design spawns a thread when a player logs in, and of course there's a lot of interthread communication going on since the players must be able to communicate and everything must be synched up to real time. There are also threads for computer 'players'. This is about as multithreaded as it gets.

The client is a Swing client, but runs the network code in a separate thread. As a result, I'm acutely aware of the multithreaded nature of Swing. The thread management is much simpler there, though, as it consists mostly of queueing Runnables to the event dispatch thread from the network thread, and queueing commands from the event dispatch thread for the network thread to handle.

I guess there's a little bit of multithreaded thinking involved in keeping the client and the server in synch, too, though I don't think that qualifies as multithreaded coding.

In answer to an earlier question, I've previously done a multithreaded project in ANSI C++, and I've found that writing this kind of complex multithreaded code is not really easier in Java. I've found the main advantage of Java in singly threaded code to be the guaranteed repeatability from the lack of undefined results. Java doesn't make the same guarantees for multithreaded code, so that advantage disappears. In some ways, writing clean multithreaded code for Java is worse, because the memory model has much more undefined behavior than C++ does on any given platform.
Helen Thomas
Ranch Hand

Joined: Jan 13, 2004
Posts: 1759
The other end, the more exciting end, is full-blown parallel computing systems like Google.

Or a massively parallel system like a regenerated mainframe.


Le Cafe Mouse - Helen's musings on the web - Java Skills and Thrills
"God who creates and is nature is very difficult to understand, but he is not arbitrary or malicious." OR "God does not play dice." - Einstein
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ali Pope:
Lasse, my question was not about how you make this technically, but rather how you compute the refresh time in order not to kill you servlet.
The polling servlet should be pretty light-weight and you can always limit the number of simultaneously running jobs if the load gets too big. If the job being computed in the background is such that you can calculate an estimated duration for completing it, you could of course log that information into the results "blackboard" so that the polling servlet can adjust the refresh period accordingly. I.e. if the job estimates that it's halfway through and the job has been running for 3 minutes by that time, it's probably safe to make the browser refresh after 2 minutes instead of 10 seconds. Then, after the 2 minute wait, if the job is estimated to finish in 45 seconds, drop the refresh frequency to 30 seconds, and so forth.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Who's using threads?