Up until recently, Web applications were "connected-only" applications. Users could only use the application by connecting to the central server and all data access was done in a single place. For many years, people accepted that was the limitation of Web applications. But it isn't a limitation any longer.

Over the past year a number of technologies have come along such as Adobe AIR and Google Gears that allow offline access to the data and the application. This is a huge boon to Web developers who, up until now, were hampered by the offline problem of Web applications. Both of these solutions employ a local, lightweight database to serve and store the data while the application is offline.

Migrating your "connected-only" application to an "occasionally connected" application will likely require significant architecture changes to facilitate the change tracking and conflict detection needed for synchronization. It's extremely important that all the architecture changes are considered, and that a synchronization strategy is designed carefully from the start.

To illustrate the complexities that occasionally connected applications bring, and to exhibit the sort of architecture changes that may be required, this article will focus on only one problem: How do you create and uniquely identify data that's created while offline?

While this is among the simplest of the synchronization problems that you'll encounter, it provides an excellent example of the changes you must consider when designing occasionally connected applications.

Why Good Old Auto-Increment Isn't Enough
To be able to synchronize and detect conflicts, all of the data records must have a unique identifier that distinguishes them from all other records. In the database world, this would be called the record's primary key. When a new record is created, it must be assigned a unique primary key to ensure that it can be uniquely identified across all instances of the application. In a centrally accessed system, the most common way to generate unique values is to use an auto-incrementing integer. Each created record is assigned a primary key that's one greater than that of the last created record. But this fast, simple method that works so well for connected-only applications simply doesn't work for occasionally connected ones.

To show why it doesn't work, consider an application that lets multiple users share a single contact list between them. The master version of the contact list resides on the central server, and a copy of that list is stored in the local database of each user's application. Assume that two users, User A and User B, synchronize their contact list with the server at the beginning of the day and then proceed to work offline. Later, while working offline, each user adds a new contact to his application. What value should they use as a primary key? Auto-incrementing seems to work fine on the server, so what happens if auto-increment is used in the offline applications? The answer: collisions.