Primary Key Pool
The primary key pool method uses a similar key reservation paradigm as used by global auto-increment. However, unlike global auto-increment (which implicitly reserves a group of keys based on application identifier and partition size) the primary key pool method explicitly reserves a group of keys by actually taking them! When a new instance of the application starts for the first time, it requests a block of unassigned primary keys from the server (see Figure 5). The server must keep track of the last primary key that it gave out to ensure it never gives out the same key twice. Each application instance is responsible for maintaining a list of the primary keys that they have obtained. This is called the application's key pool. Each time the application wishes to add a record, it takes a key out of its key pool and uses it.

In the contact list example, User A's application requested the first five keys, key zero through four, for its key pool. Later, User B's application requested keys five through nine. When each user wants to add a contact, his application simply removes a key from its key pool and uses it. If an application runs out of keys, it can't add any more contacts until its key pool is replenished by requesting more keys from the server.

Like the UUID method, primary key pools don't require a unique application identifier. But the real power of this method is that it's the most likely to integrate seamlessly with your current application. It's unlikely you chose UUID as your primary key when you first developed your connected-only version of the application. If you wanted to use the UUID method you would have to convert all of your current primary keys over to UUID, which may be very difficult or impossible. The primary key pool has the least impact on your current architecture.

The drawback to this method is that it's certainly the most complicated to set up. It also requires additional storage in the application to keep track of the keys currently reserved in its key pool. But its lack of an application identifier requirement and its seamless integration into existing applications make it a very attractive choice.

Tip of the Iceberg
This is not intended to be an exhaustive list of the solutions to this problem. There are certainly many more. Instead, it's intended to get you thinking of what changes you may need to make to your architecture as you start to design your occasionally connected application.

Primary key generation is just the tip of the iceberg in planning a fully fledged synchronization strategy. This article has only considered the creation of new records. In reality, your application will also need methods to do change tracking and conflict detection when users want to update or delete records (a much more challenging problem!). Just as there are solutions to the primary key problem, there are solutions to the other synchronization problems as well.

The key is planning ahead. The time you spend designing your synchronization strategy at the start will be repaid tenfold in the time saved debugging bad synchronizations and refactoring your code.