Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / July 2006

Tip: Looking for answers? Try searching our database.

Handling Idempotency on server side

Thread view: 
hemant.singh@gmail.com - 23 Jul 2006 08:33 GMT
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
Chris Uppal - 23 Jul 2006 08:59 GMT
> 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
hemant.singh@gmail.com - 24 Jul 2006 06:00 GMT
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

> > Request1 comes we will set the flag for that session as PROCESS_PENDING
> > until we finish the complete processing, now before even process is
[quoted text clipped - 27 lines]
>
>     -- chris
Chris Uppal - 25 Jul 2006 10:13 GMT
> 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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.