Hi again, Let me correct the observation made here. Unlike another issue I have been investigating, this concurrency issue does turn up with IE for a simple JSP forward too. It is not specific to the use of a Struts forward.
Vaughan. > -----Original Message----- > From: Vaughan Jackson [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 11, 2002 6:07 PM > To: '[EMAIL PROTECTED]' > Subject: Potential Concurrency Issue - Struts Forward/Frames/Internet > Expl orer 6.0 > > > Hi, > > We have been looking at the implementation of an out of order request > detection mechanism very similar to the one built in to > Struts. For a single > frame application, this works as follows, upon reception of a request: > > 1. The action object extracts a token (if any) from the > session, and stores > it as > 'the old token'. > 2. The action object then generates a new token to identify > the current > request, and places this token in the session. > 3. The action object compares the token it extracts from the > current request (if any) with 'the old token', that previously in the > session. > They should match. If they don't, then the current request is > classified > as an 'out of order' or duplicate request. The action object > can change > the request's action to something else, if it is thought that > duplicating > the > action in question might be harmful. > 4. The request is forwarded to the corresponding JSP page. > 5. Code on the JSP page extracts the token from the session, > and makes it > the value of a hidden form field. > 6. If the page and its form are subsequently submitted, the > token value will > be > submitted as part of the request. The "loop" begins again > from step 1. The > token > submitted here in step 6 will be compared in step 3. > > This seems to work well for detecting duplicate requests > resulting from the > user hitting > the reload/back or forward buttons on the browser. > > Then we tried to apply the same approach to a framed application. The > problem with > a framed application is that each user action can result in a > number of > requests, > hence we can't assume that an in order request's token value > should match > the > last one generated but one. > > A colleague came up with a solution for this. Instead of just > getting the > pages to submit > whatever value they pick up from the session at time of > rendering, we get > each page > to store the value extracted from the session at the time of > rendering in a > JavaScript > global variable, or one on the top level window. Then, at time of > submission, the page > picks up this value from the JavaScript, and submits this. > The rest of the > process > should work as before. The important point here is that this > JavaScript > variable is > shared by all requests, and thus, we effectively end up with one token > identifying > each user action, rather than one for each request. All of > the requests from > a single > user action should be submitted with the same token value. > > This seemed to work fine in both Internet Explorer 6.0 and > Netscape 6.2. > Then I > discovered one problem. In a particular test case, I would get the > application to > carry out a Struts forward action to the page containing the frameset > containing > the pages in question. Then, I would invoke an action on one > of those pages > to see > whether the application thought such a request was a > duplicate or not. It > should not. > Generally it did not. However, about 1 in every 10 times, > with Internet > Explorer only, > the tokens would not match, and it would come up with a > "false positive". It > would > classify the first instance of a request as a duplicate. > > Has anyone else seen this sort of behavior? It seems to be something > peculiar to the combination of a Struts forward to a frameset > followed by > the action in question, when using IE only. Is is possible > that this is > occuring > due to some sort of race condition? > > Any ideas welcome. > Thanks, > Vaughan. > ___________________________________________________ > Vaughan Jackson > Development > Tumbleweed Communications > [EMAIL PROTECTED] / +1 (650) 216 2532 > ___________________________________________________ > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
