On Wed, 10 Sep 2003, Jing Zhou wrote:
> Date: Wed, 10 Sep 2003 02:16:49 -0500
> From: Jing Zhou <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
> Jing Zhou <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> 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.
>
Technically, the threads are usually there already in a pool, rather than
being created, but that is not really relevant to your question.
The only ways the same browser window can send more than one request
(in the manner you describe) are:
(a) User presses STOP and then manually triggers a second request.
(b) A page includes one or more tags like <img> that fire
off parallel requests for each image
(c) Window includes multiple frames (the frames themselves
are often loaded with parallel requests) just like (b)
(d) JavaScript techniques similar in (b) that are used by the client
to reassemble the output.
So the answer to your question really depends on which use case we're
talking about. In scenario (a), thread A will continue to run the
original request, because the server has no way to know that the user
pressed STOP. Because the client has closed the TCP connection, the
servlet will generally encounter an I/O exception when writing out the
response -- but if the response fits inside a buffer, it might not be seen
until after the servlet returns.
In scenarios (b) - (d) the requests run in parallel and the client
assembles the resulting page.
> 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.
This is my scenario (a) use case, and behaves as I described above.
> 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?
The key problem in dealing with scenario (a) is detecting that it has
even happened. The most important case is when you're doing a POST that
updates the database -- for example, you don't want an order to be
submitted twice simply because the user pressed SUBMIT, hit the back
arrow, and pressed SUBMIT again. The "transaction token" facility
provided by Struts can be used to detect the second submit.
Note that there is an API called "SingleThreadModel" in servlets, but it
has nothing to do with this kind of problem, and should be avoided anyway
(it's being deprecated in Servlet 2.4) because it doesn't really solve all
of the problems that it tries to solve.
>
>
> Jing
> Netspread Carrier
> http://www.netspread.com
>
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
