On Wed, Sep 10, 2003 at 03:17:35PM -0700, Craig R. McClanahan wrote:
What we found in IE 6.0 sp1 is that end users do not have to press
STOP and then manually trigger a second request. They could just
press buttons in a web form and trigger different requests to the
server. Is this a bug
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
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
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
Andrew Hill [EMAIL PROTECTED] wrote:
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
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
Actually Id have to disagree with you about the requests for a particular
session not needing to be multithreaded.
For example in the app I was working on recently we needed the ability for
the user to pop up (yes I know - I dont like it either) lots of editing
windows for records selected from
- Original Message -
From: Andrew Hill [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Wednesday, September 10, 2003 3:18 AM
Subject: RE: What's the best strategy to handle this kind of thread issues?
My undertsanding was that the browser will only show the
- 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
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
On Wed, 10 Sep 2003, Jing Zhou wrote:
[snip]
It is very likely for the browser window to use the same connection to send
request A and B (with the keep alive setting). But I am not 100% sure for
this. Any Tomcat users or experts could provide some clue?
This is actually more an issue of the
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]; Jing
Zhou [EMAIL PROTECTED]
Sent: Wednesday, September 10, 2003 12:12 PM
Subject: Re: What's the best strategy to handle this kind of thread issues?
On Wed, 10 Sep 2003,
Jing Zhou [EMAIL PROTECTED] wrote:
What we found in IE 6.0 sp1 is that end users do not have to press STOP
and then manually trigger a second request. They could just press buttons
in a web form and trigger different requests to the server. Is this a bug
in IE 6.0? (The scenario (a) looks
- Original Message -
From: Mike Kienenberger [EMAIL PROTECTED]
To: Jing Zhou [EMAIL PROTECTED]; Struts Users Mailing List
[EMAIL PROTECTED]
Sent: Wednesday, September 10, 2003 1:56 PM
Subject: Re: What's the best strategy to handle this kind of thread issues?
Jing Zhou [EMAIL
On Wed, 10 Sep 2003, Jing Zhou wrote:
Date: Wed, 10 Sep 2003 13:49:18 -0500
From: Jing Zhou [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Cc: Craig R. McClanahan [EMAIL PROTECTED]
Subject: Re: What's the best strategy to handle this kind of thread
issues?
-
Consider this timeline as a possible solution:
1. Form is submitted, token is invalidated.
2. Form submitted again; error cause token is invalid; sit there and check
lost and found for HttpServletResponse that original request will generate
and leave there.
3. Request A is processed and
snip
What we found in IE 6.0 sp1 is that end users do not have to press STOP
and then manually trigger a second request. They could just press buttons
in a web form and trigger different requests to the server. Is this a bug
in IE 6.0? (The scenario (a) looks correct in IE 5.0)
/snip
Ive seen
- Original Message -
From: Andrew Hill [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]; Jing
Zhou [EMAIL PROTECTED]
Sent: Friday, March 03, 2000 10:34 PM
Subject: RE: What's the best strategy to handle this kind of thread issues?
snip
What we found in IE 6.0 sp1 is
snip
In IE5 (which is what Id been developing with) the code caused no problems,
but in IE6 clicking the submit button would cause a natural submit to occur
AND my javascripts submit() would also work, resulting in a second request
swiftly following the first (and generally resulting in a error).
hehe,
my way is less subtle.
I change the visibility style on most of the page (including the button) to
invisible, and reveal a section containing a please wait message. (Wont work
on older browsers, but our they dont meet this particular apps minimum
requirements anyhow).
Its also quite nice
On Thu, Sep 11,'03 (01:06 PM GMT+0800), Andrew wrote:
I change the visibility style on most of the page (including the
button) to invisible, and reveal a section containing a please wait
message.
Excellent! I'll have to use this myself. Thanks!
--
Rick
21 matches
Mail list logo
