«

Hello Dude,

Say same client send request 2 times by pressing "submit" button one
after another
- Request1
- Request2

Now say if we keep flag on the server side
PROCESS_PENDING
PROCESS_DONE

Request1 comes we will set the flag for that session as PROCESS_PENDING
until we finish the complete processing, now before even process is
finished client send request2 but we will reject this request2 as
server is processing request1, but for browser he forgot request1 and
expect reply of response2 only and thus browser showing empty page, att

There is already client side javascript which will prevent idempotency
but im just wondering about the clients which have javascript
disabled...

Hemant

wrote:

> Request1 comes we will set the flag for that session as PROCESS_PENDING
> until we finish the complete processing, now before even process is
> finished client send request2 but we will reject this request2 as
> server is processing request1, but for browser he forgot request1 and
> expect reply of response2 only and thus browser showing empty page, att

Some options:

1) Cancel the ongoing processing and start again from the begining.

2) Wait until the ongoing processing is complete and then start the new
processing (igoring the fact that it might duplicate the original effort).

3) Similar to (2) but more complex, maybe less reliable, and probably not worth
the effort: wait for the ongoing processing to complete and then replicate the
response to the original request as the response to the new request.

4) Fail the new request with some informative message.

5) Design the architecture so that it /can't/ allow the same request to be
issued twice -- e.g. each request must have a separate serial number which is
issued in a separate step before the request can be made.

I don't /think/ there are any other options...

Note that in general, unless your architecture is such that two independent
clients can't request the same action at about the same time, then your
solution will likely be similar (or identical) to what you would do in that
situation.

-- chris

Chris,
I think you have listed all the possibly available options.
I think option 3 looks best, as it will give same experience to user as
in case when javascript is enabled, but im try'g to implement it but
seems like browser won't take anything from response2, so we need to
change somehow response1 instance with response2 before we write to
client, now this looks like most feasible option to me as customer want
this only, now im just thinking best ways to implement
- We need to assume here that if customer send any request after we
start writing on the last response instance than there is no way to
handle it and this will again lead to problem, im sure this is like one
in maybe 10,000 case that will happen, but this step is so critical I
can't afford to make client see empty page.

Best option is though put a intermediate page like it comes in most
cheap airticket search sites so that user don't have option to send
another request, but this is not possible at this stage in product.,
Would love to hear comments from you.

Hemant

Chris Uppal wrote:
> wrote:
>
> > Request1 comes we will set the flag for that session as PROCESS_PENDING
> > until we finish the complete processing, now before even process is
> > finished client send request2 but we will reject this request2 as
> > server is processing request1, but for browser he forgot request1 and
> > expect reply of response2 only and thus browser showing empty page, att
>
> Some options:
>
> 1) Cancel the ongoing processing and start again from the begining.
>
> 2) Wait until the ongoing processing is complete and then start the new
> processing (igoring the fact that it might duplicate the original effort).
>
> 3) Similar to (2) but more complex, maybe less reliable, and probably not worth
> the effort: wait for the ongoing processing to complete and then replicate the
> response to the original request as the response to the new request.
>
> 4) Fail the new request with some informative message.
>
> 5) Design the architecture so that it /can't/ allow the same request to be
> issued twice -- e.g. each request must have a separate serial number which is
> issued in a separate step before the request can be made.
>
> I don't /think/ there are any other options...
>
> Note that in general, unless your architecture is such that two independent
> clients can't request the same action at about the same time, then your
> solution will likely be similar (or identical) to what you would do in that
> situation.
>
> -- chris

wrote:

> Best option is though put a intermediate page like it comes in most
> cheap airticket search sites so that user don't have option to send
> another request, but this is not possible at this stage in product.,
> Would love to hear comments from you.

I don't think that /any/ of the options I mentioned can be expected to be easy
to implement. /If/ the possibility has been considered from the start, and has
been designed for, then presumably it would be easy to do, but that doesn't
sound as if it applies in your case. So, unless your web framework has the
built-in ability for different requests to "communicate" with each other, it
sounds as if whatever you do is going to be a fair bit of work.

Under the circumstance, the "intermediate page" might be the cheapest option.

Beyond that, I'm afraid I can't help -- it would depend on details of your
application architecture (including web framework, if any), which I'm obviously
not familiar with.

-- chris