Response.Redirect not firing due to code to prevent re-submission

I have an event which needs to co开发者_StackOverflowntact some third party providers before performing a redirect (think 'final payment page on ecommerce site') and hence has some lag associated with its processing. It is very important that these third party providers are not contacted more than once, and sometimes impatient users may try and refresh the page (hence re-submitting the data). The general code structure is:

If Session("orderStatus") <> 'processing' Then

    Session("orderStatus") = 'processing'

    DoThirdPartyStuffThatTakesSomeTime()

    Response.Redirect("confirmationPage.asp", True)

End If

The problem is, if the user refreshes the page, the response.redirect does not happen (even though the rest of the code will run before the redirect from the original submission). It seems that the new submission creates a new thread for the browser which takes precedence - it skips this bit of code obviously to prevent the third party providers being contacted a second time, and since there is no redirect, just comes back to the same page. The whole second submission may have completed before the first submission has finished its job.

Any help on how I can still ignore all of the subsequent submissions of the page, but still make the redirect work...?

Thanks

---

Move you redirect out of the if structure:

If Session("orderStatus") <> 'processing' Then

  Session("orderStatus") = 'processing'

  DoThirdPartyStuffThatTakesSomeTime()

End If

Response.Redirect("confirmationPage.asp", True)

---

After a bit more research and investigation (including alot of tracing and tracking what was firing and when using session variables) I found that ASP.NET automatically serialises requests for a given session, so that each one will execute in turn. However (and this is what confused me), the 'Response' delivered to the browser is the result of the last action performed (assuming this action was initiated before the browser received a response to the previous action). So, in my case above, all the third party code initiated by the first request finishes execution before the second request even starts. When all the requests are finished processing, ASP.NET obviously delivers the HTML back from the last request to IIS (which happened to be just a refresh of the page).

So, Oded's first suggestion above about moving out the redirect was correct - and I've marked this with the answer.