Commit protocol

Question

Hi,

I'm building a REST web service that receives a request and must return "Ok" if the operation was done correctly. How could I deal with the possibility of the loose of the connection while returning this "Ok" message?

For example, a system like Amazon SimpleDB.

1) It receives a request. 2) Process the request (store and replicates the content). 3) Return a confirmation message.

If the connection was lost between phases 2 and 3, the client thinks the operation was not successful then submits again.

Thanks!

Answer 1

A system I reviewed earlier this year had a process similar to this. The solution they implemented was to have the client reply to the commit message, and clear a flag on the record at that point. There was a periodic process that checked every N minutes, and if an entry existed that was completed, but that the client hadn't acknowledged, that transaction was rolled back. This allowed a client to repost the transaction, but not have 2 'real' records committed on the server side.

Answer 2

In the event of the timeout scenario, you could do the following:

Send a client generated unique id with the initial request in a header.

If the client doesn't get a response, then it can resend the request with the same id.

The server can keep a list of ids successfully processed and return an OK, rather than repeating the action.

The only issue with this is that the server will need to eventually remove the client ids. So there would need to be a time window for the server to keep the ids before purging them.