views:

37

answers:

1

I have a launchd daemon that every so often uploads some data via a web service using NSOperationQueue.

I need to be able to persist this data, both so that it can later be re-uploaded in the event of failure, even between sessions (in case of computer shut down, for example).

This is not a high load application, it probably receives items intermittently no more than 1 or 2 every minute, often with several hour gaps in between.

My initial implementation without this persistence in place is as follows:

  1. Daemon receives data.
  2. Daemon parses data into an object of type MyDataObject.
  3. Daemon creates instance of NSOperation subclass with MyDataObject as the object to upload and adds it to its NSOperationQueue.
  4. NSOperationQueue goes through and uploads MyDataObject via web service as it is able.

This part all functions just fine. The part I now want to add is the persistence in case of web service failure, computer shut down, etc.

It seems like I could use an NSMutableArray of MyDataObjects along with NSKeyed(Un)archiver containing all the items which had not yet been uploaded and observation of the -isFinished key of all the operations to remove items from the array, but it seems like there should be a simpler way to do is, with less room for things to go wrong, especially as far as thread safety goes.

Can somebody point me in the right direction?

+1  A: 

You could add two operations per item. The first would store the item to local storage, and the second would depend on the first and would remove the item from local storage on success.

Then, when you want to restore any items from local storage, you create only the store-to-the-cloud operations, not the store-locally operations. As before, they remove the items from local storage only if they succeed, and if they don't succeed, they leave the items in local storage for the next attempt.

Peter Hosey