On Tue, 2003-10-28 at 14:18, Justin Ruthenbeck wrote: > At 04:20 PM 10/27/2003, you wrote: > >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."
While the logic on the server is reasonably fast, we can't be sure that the network latency is so low that the user can't double click, nor that the server will always be fast all the time. In fact we have several cases of this actually happening and two records being created on the server. > 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). We do have concurrent update checking which catches this problem in most cases. However that solution does not work when creating a brand new record. From the server point of view it appears to be two requests to create a record, which just happen to have the same details (and in this case we don't want to prevent the user creating apparently duplicate records, so that isn't a solution). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
