I created a web service and a mobile application that communicate between each other. When everything is working, it works great. When the server doesn't respond, it starts to break down.
The mobile device sends a message to the server with a bunch of records. Getting the records on the server never seems to be a problem. It gets the records and then sends a response back to the mobile device that the update was received. The PROBLEM is that the mobile device doesn't always get the response, so it doesn't know it shouldn't send those records again for updating.
Next time it sends the records again and now I have duplicate records. How can I solve this?
Idea 1) Create a transaction number unique on the mobile device that I can compare against the server to see if the record was already uploaded. Then just don't write that record and attempt to send back the response that it was written.
Idea 2) Send the records to the server, but before writing them respond to the mobile device that they were received. This way the mobile device can tag them and then send another response to the server telling it to write them. At the point the mobile device almost doesn't care if it gets a response. Only thing, you don't know if the server ever got the message.
Looking for ideas on how to handle this that either confirm one of these ideas or has a completely different one.
I ended up creating logs that the device attempts to resolve when it gets back successful responses from the server.
I tag items as a batch of lines and send them up to the server. Once they are up there, I create a log about the success or failure of each line item in a batch of items and then save the log to the file system.
When the mobile device is unsuccessful in hearing back a response from the server, in rare cases, it asks the server about a batch number. If the server doesn't respond with a status of that batch, it assumes the server never received it and remarks those items for another upload attempt. If it hears back, it processes the success and failure line by line and then marks the items on the mobile device accordingly. If the mobile device doesn't ask about the log in the next upload, the server assumes the batch's lifecycle is complete and it no longer needs to maintain that log. It is then deleted.
The server doesn't delete a log until it has a successful request from the specific device no longer asking to hear about the log. So if I have log 1 on the server and the device doesn't ask in the next upload to hear back about that log, the server then removes that log assuming the device got the response it wanted or doesn't care about it anymore.