On Tue, 2003-10-28 at 12:51, Justin Ruthenbeck wrote:
> Server side, instead of putting a token in the session when the page is
> *served*, put a token in the session while the submission is being
> processed (use it like a semaphore). The token has a finite lifecycle
> (created on form submission, death on submission response
> served).
This only works if processing the two submissions overlaps. If the logic to process the submission is very fast, or there is a long delay between submissions, then this won't work.
<from original post> I've designed my workflows so that they do not need to store anything in the user's session. This allows the user to conduct more than one instance of a particular task at the same time without data getting mixed up. However this presents me with a problem if the user double clicks the submit button and causes the server to do something twice. </from original post>
If the logic to process the submission is very fast, then presumably your client would have a response before clicking the submit button again. If there is a long delay between submissions, then you're dealing with an entirely different problem -- ie not "user double clicks the submit button."
If you're truly worried about multiple submissions over long periods of time, then it sounds like your system is more transactional in nature. That is, the system generates an eligible transaction on one call (form request), then executes that transaction on another (form submit). In this case, controlling the execution of code should be done on the transaction object level (not request level).
justin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
