Demo VII: Tombstone Cleanup and Detecting Stale Offline Clients
Ready for a new offline application demo? This one is really cool. In this demo I tried to show off one important feature of the framework design and how to use it to elegantly solve one common issue with synchronization systems. So let’s first talk about the problem we trying to solve.
Tombstone Cleanup
Recall that we needed to track changes on the server database and the way we do that is by adding extra tracking columns along with triggers. This suffices for tracking inserts and updates. For deletes, we typically store deleted row (or its PK only) in a separate table, we call it “tombstone table”. Now as deletes accumulate, the size of the tombstone table grows and consumes disk space. This is a problem. Tombstones are deletes after all and keeping them or even metadata about them is a growing headache that needs to be addressed. That said, the solution is to cleanup older tombstones based on some aging criteria, for example, tombstones more than a month old must be cleanup. This is all good, but what about sync clients that have not synchronized in more than a month and now are coming back to synchronize. This is a problem and a serious one too. You don’t want a client with stale content synchronizing with the server who has forgotten some metadata that is needed for this client. The solution for this problem is to detect and prevent stale clients from synchronizing and in some way tell them to reinitialize their local store.
Identifying Stale Clients
Synchronization service architecture is designed around opaque sync anchor. The runtime does not ask what it is or what it has inside, it just carries it from the server to the client and stores it at the client database for the next sync. The server side developer has all the rights to define what the anchor looks like. After all, the server side commands are the ones that make use of the anchor to enumerate changes and detect conflicts. With that in mind, I thought about recording the last datetime value when a given client synchronizes and store it in the anchor. This way the server remains stateless. When the client synchronizes again, I wrote code to desterilize the anchor and grab the datetime of the last sync. If the client has not synchronized in the last n days, I fire exception and reject client sync request.
The opaque anchor model is an interesting feature of the framework and one that could have a lot of applications if your scenarios. The idea is that the client store can be a good place for state information leaving the server focusing on performance and scaling business instead of house keeping.
Take a look at the demo and let me know what you think.
Update: Just to let you know, I left Microsoft to start a new company, Raveable Hotel Reviews . See Examples: Romantic Hotels in Myrtle Beach , Top 10 Hotels in Seattle , 5 Star Hotels in Miami, Hotels with in-room jacuzzi, Family Friendly hotels in Anaheim and Best Hotels in Fort Lauderdale . Your feedback is welcome ontwitter.com/raveable, raveable blog.
Comments
- Anonymous
May 28, 2007
It seems a bit complicated to me. I have a podcast up about what I've found that works: http://udidahan.weblogs.us/2007/04/17/podcast-occasionally-connected-smart-clients-and-adonet-sync-services/ My application server also publishes messages containing information about how its data changes. Clients simply subscribe to these messages, and the messaging infrastructure maintains these old messages using what's known as durable subscriptions. No need for a tombstone table or to detect stale offline clients. Everything just works. Probably because it's designed for the disconnected case from the ground up. What are your thoughts about this kind of solution?