It doesn't really defeat the effort - the only threads that will be sitting there waiting are those that are processing requests that have come from that particular form on that particular users browser where the user has gone and double clicked submit etc... and we want things to proceed ok without showing an error screen - and without saving the record twice in the db (or whatever).
At any rate its unlikely to be worth the effort for most applications. I present it more as an intellectual exercise than a serious proposal, (though another Mike in a reply that just arrived mentions that WebObjects does something not unlike this already so maybe its not so bad. Ill have to go take a look at WebObjects if I ever get any free time...) The simplest thing Ive found is to use some javascript on the client side to minimise the potential for multiple submission of the form, and for those cases it lets through (such as where js is disabled) the old fashioned method of checking the token & showing an error page if its a double submission will have to suffice. This of course is what we all do now anyway, but a more elegant (from the user perspective) solution would be nice. -----Original Message----- From: Mainguy, Mike [mailto:[EMAIL PROTECTED] Sent: Wednesday, 10 September 2003 22:14 To: 'Struts Users Mailing List'; '[EMAIL PROTECTED]' Subject: RE: What's the best strategy to handle this kind of thread issues ? I think, however that this proposed solution (almost) entirely defeats the purpose of having a multithreaded environment. If you try and synchronize all responses and disregard duplicates, you will most likely end up with a slow and cumbersome application. I would say to achieve the sort of efficiencies you are describing one would be better served to look into the app/web server code. Doing this at a servlet level will most likely just get one into a big mess. It actually seems like a good idea (if it isn't already there) for a caching proxy or appserver, but certainly not a web application. Just my $.02 -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 4:18 AM To: Struts Users Mailing List Subject: RE: What's the best strategy to handle this kind of thread issues? 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] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
