----- Original Message ----- From: "Mainguy, Mike" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, September 10, 2003 9:14 AM 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. Swing takes advantages of multithreaded environments. But its event handling model does use single thread to execute queued events. Such mechanism does not cause slow responses at all, both in theory and in reality. How to get it done in web tiers is an open challenging. my $.02 Jing > > 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]
