User creates a folder in client and in the client-side code I hit an API to the server to make this persistent for that user. But in some cases, my server is so busy that the request timesout. The server has executed my request but timedout before sending a response back to client. The timeout set is 10 seconds in client. At this point the client thinks that server has not executed its request (of creating a folder) and ends up sending it again. Now I have 2 folders on the server but the user has created only 1 folder in the client. How to prevent this?

One of the ways to solve this is to use a unique ID with each new request. So the ID acts as a distinguisher between old and new requests from client. But this leads to storing these IDs on my server and do a lookup for each API call which I want to avoid.

Other way is to increase the timeout duration. But I dont want to change this from 10 seconds.

Something tells me that there are better solutions.

I have posted this question in stackoverflow but I think its better suited here.

UPDATE: I will make my problem even more explicit. The client is a webbrowser and the server is running nginx+django+mysql (standard stack). The user creates a folder in webbrowser. As a result I need to hit a server API. The API call responds back, thereby client knows API call was success. This is normal scenario. Sometimes though, server successfully completes the API request but the client-side (webbrowser) connection timesout before server can respond back. The client has no clue at this point. The user thinks the request was a fail & clicks again. This time it was a success but when the UI refreshes he sees 2 folders. I want to remedy this situation.

1 Answer 1


Sounds like you are working in a distributed network environment, have transactions that one node expects another node to carry out reliably and you are specifically dealing/experiencing with timeouts. This is a relatively generic problem that many people had to solve at one time or another. Take a look at the three-phase commit protocol and see if that would be suitable for your application. Or possibly two-phase commit is good enough for what you are doing.

  • well, what you have posted is interesting but not sure how it helps me. Please read my question UPDATEs above... Nov 30, 2012 at 5:11
  • and there I go thinking that I did answer your question. The way I see it "create folder" in your app is a transaction. It is not good enough for the server to carry out the task and leave it at that. The handshake (i.e. all phases) must complete so that both parties are in sync. If this handshake doesn't happen, the server should roll back the change. As far as timeouts, I think 10 seconds is more than reasonable and I wouldn't make timeout more than that. Regardless of your timeout value, you must write code with assumptions that failures will occur and your client must handle those cases.
    – DXM
    Nov 30, 2012 at 5:16
  • So transactions will guarantee that client and server stay sychronized. If request times out, the client should be able to retry if needed. And other than that, you might want to take a closer look at your server and see why it is so loaded that it takes 10+ seconds to process a request. That doesn't seem healthy, so either your server needs to be optimized or you need to scale out (vertically or horizontally) your hardware
    – DXM
    Nov 30, 2012 at 5:17
  • 1
    this is your custom application, so there's plenty of things under your control. For example, what happens after 10 sec timeout? does client continue as if it's business as usual? If a request was sent and response was never received, I would make my client assume that communication link has been broken. It shouldn't just hope that maybe next request will succeed. So a) stop whatever you are doing and b) schedule reconnects. As part of a reconnect, the client should probably refresh the UI/data cache and with that refresh it will get the new folder info
    – DXM
    Nov 30, 2012 at 6:09
  • 1
    not sure how keep-alive would help. You'd use keep-alive with connections that don't see a lot of traffic as 1) a way to test and ensure server is still accessible (you might want to know this asap, rather than wait for when you actually send a real request to the server) and 2) to keep the server from closing its end because it may not know that the client is still online. However, even with keep-alive you still have the same timeout issues to worry about. Keep-alive is still request/response just with no useful info other than "here I am"
    – DXM
    Nov 30, 2012 at 6:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.