views:

363

answers:

1

I am working on syncing two business objects between an iPhone and a Web site using an XML-based payload and would love to solicit some ideas for an optimal routine.

The nature of this question is fairly generic though and I can see it being applicable to a variety of different systems that need to sync business objects between a web entity and a client (desktop, mobile phone, etc.)

The business objects can be edited, deleted, and updated on both sides. Both sides can store the object locally but the sync is only initiated on the iPhone side for disconnected viewing. All objects have an updated_at and created_at timestamp and are backed by an RDBMS on both sides (SQLite on the iPhone side and MySQL on the web... again I don't think this matters much) and the phone does record the last time a sync was attempted. Otherwise, no other data is stored (at the moment).

What algorithm would you use to minimize network chatter between the systems for syncing? How would you handle deletes if "soft-deletes" are not an option? What data model changes would you add to facilite this?

+6  A: 

The simplest approach: when syncing, transfer all records where updated_at >= @last_sync_at. Down side: this approach doesn't tolerate clock skew very well at all.

It is probably safer to keep a version number column that is incremented each time a row is updated (so that clock skew doesn't foul your sync process) and a last-synced version number (so that potentially conflicting changes can be identified). To make this bandwidth-efficient, keep a cache in each database of the last version sent to each replication peer so that only modified rows need to be transmitted. If this is going to be a star topology, the leaves can use a simplified schema where the last synced version is stored in each table.

Some form of soft-deletes are required in order to support sync of deletes, however this can be in the form of a "tombstone" record which contains only the key of the deleted row. Tombstones can only be safely deleted once you are sure that all replicas have processed them, otherwise it is possible for a straggling replica to resurrect a record you thought was deleted.

Jeffrey Hantin
Thank you for your feedback. I think the issue you've brought up regarding time skew is important.My initial hope is that between NTP on the server and the iPhone/Touch's own time syncing services with the carrier/computer - time skew issues will be mitigated. Is this assumption too dangerous?
hyuan
It's fragile in a lot of ways -- for example, a clock being reset backward can cause missed updates as well, and missed updates can result in undetected edit conflicts. Multi-master replication is a nontrivial task.
Jeffrey Hantin
Thank you for the kind advice. Hopefully in a couple of weeks, you'll be able to see the fruits of your wisdom. The site in question is already up (www.ayenotes.com) but the iPhone app is not.
hyuan
I don't even recognize what's at that domain now.
Jeffrey Hantin