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 ]
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.
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.
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.