My undertsanding was that the browser will only show the response to the the second of the requests - forgetting about the first. The server of course hasnt forgetten about it and keeps processing (one hopes). Im not quite sure what happens to its response stream (>>null?) but the browser is now only waiting for the second requests response - which I presume is a seperate connection?
Now if we are using tokens or some such mechanism to detect that its a second request and thus illigitimate then we can of course return some kind of error to the user instead of processing the request (since we know its already been processed). This however isnt very friendly. What we really want to do is to have the second request return the same response as would have been returned by the first request after it did its work. I have no practical solution for this :-( Hmm. Actually I have an idea. Not a good one, but maybe worth a passing thought: (Thinking off the top of my head here btw (and the following will not work in a distributed environment unless one has sticky sessions so that all requests for a particular session are gauranteed to be processed by the same JVM)): 0. Requests A,B,C,N come in in rapid succession and cause threads to be started in the container to process the requests - probably but not necessarily in the order they came in. 1. Thread B (or any other thread) is lucky enough to start running first and. Synchronizing on some global object (probably its own Class object if its a singleton) it checks the session for a token (under a key that was generated earlier and submitted as a request param in a hidden field). Not finding it, it creates it and stores it in the session, and proceeds to marshall the data needed to render a response - whatever it is the action is supposed to actually do. 2. Threads A,C,N also sync on the global object and check the session. Unlike thread B, they find the token, so they all call wait() on the token object. 3. Having doing the processing & read/updated the db (or whatever), and obtained the necessary info, etc... Thread B is finally ready to render a response. It doesnt know however if it is the 'lucky last' thread that the browser is actually waiting for. What it does then is to add the necessary information to render the response to the session (perhaps the token could provide getters for it?), and having done so it calls notifyAll() on the token object, and then proceeds itself to forward to the view. 4. Threads A,C,N are woken up by the notify(), and proceed to grab the necessary info from the session to render the same response that B is now rendering and forward to the view. (NB: we shall assume that the view (jsp or velocity template or whatever *only* renders the view and doesnt change any of the information is uses to render the view (with one notable exception) - and that that info can be read by multiple threads at once!). One of these 4 threads is the lucky one (N in this example) that will actually have their response output on the browser. 3 of them are wasting time rendering to nowhere - but they are all rendering identical html, and the user will get an appropriate response page instead of an error. 5. After they have finished rendering and flushed the 4 threads all try to remove the token from the session. (You will note that if another request comes in at this point we are in trouble. We could of course leave the token in the session along with all the response data just in case but then we would run out of memory after a while... (maybe we could use some kind of self expiring cache? hmmm)) -----Original Message----- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Wednesday, 10 September 2003 15:17 To: Struts Users Mailing List Subject: What's the best strategy to handle this kind of thread issues? As we realize so far, a browser window may send request A to a server. The server starts thread A to handle it. Before the thread A returns, the same window may send request B to the server, therefore the server creates thread B to handle it. Assuming thread B finishes earlier than thread A, we could have the following possibilities: 1) The server waits thread A to finish and send response A and then send response B. (I do not believe this is the Tomcat implementation, correct?) 2) The server sends response B back to the browser window and the browser window displays it and ignores response A after it. 3) The browser displays response B and then displays response A. What I can see is that thread B is the trouble maker. But it is possible when end users click more than one buttons. In Swing, such problems are resolved by Single Thread Model. Should we follow Single Thread Model at servers? Are there any other practical solutions to it out there? Jing Netspread Carrier http://www.netspread.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
