Count-Based Replication (Windows CE 5.0)
The count-based replication method maintains generation counters on the objects being replicated. The replication APIs provide an interface for writing an application, a synchronization client that uses the replication APIs to obtain a set of changed items in the databases and file system of the target device. The synchronization client then sends those items, by any method, to the distant store being synchronized, such as a database on a computer or a mail server. The client computer can also use the standard Windows-based desktop platforms file APIs and database APIs to write changes onto the target device.
You can conduct synchronization using count-based replication by opening a synchronization session and performing all activities while that session is open. The following three functions open and close synchronization sessions:
The session is described by a state, an opaque buffer of data that the synchronization client computer may store, such as by writing it to a file. The synchronization client computer can then use the state when opening its next session to restore the previous session at the point where the state was saved. In this manner, the synchronization client computer can operate a session at separate times and maintain the state of its synchronization even when that session is closed.
A synchronization session can be opened on the object store, which contains file and database items, or on a separate database volume, which contains only database items. A synchronization client computer may only open one session at a time on a single volume, counting the object store as a special volume, though it may open sessions on more than one volume at a time.
As an example of the way a session can be conducted, a synchronization client may start out by opening a new synchronization session with ReplOpenSync. It can read all of the changed items, on the first read for all items on the target device, and copy them to the distant object store using its own methods. It can also use the Windows-based desktop platforms file APIs and database APIs to write changes that originated on the distant object store. At any time, though usually when synchronization is complete, it can use ReplGetSyncState to obtain a buffer of state data, save the data away, and close the session using ReplCloseSync. Later, it can resume the session by calling ReplOpenSync with the saved state buffer.
The following two functions are available for reading changed items:
These functions are used to determine which items have changed and some information about the nature of the change, including creations, modifications, and deletions. ReplFindNextChange is an enumerator that returns a sequence of changed items; it is useful when all data inside the object store or database volume is being replicated. ReplGetOidStatus obtains the status of a single item, whether it has changed or not, and is useful when only a single item, or a known set of items, is being replicated.
As the data being replicated can be added, modified, or deleted by any application at any time, synchronization is a continuous process. Count-based replication operates by breaking up the series of changes on the target device into sets that are then read in groups. For example, a synchronization client computer can use ReplFindNextChange to read all changed items in the object store or database volume and at some point there will be no more changed items. Once the client computer reaches that point, it can call ReplCheckpoint to commit that it has read and written all that is required. The checkpoint indicates that the client computer has read all data possible. Checkpointing is important because modifications by other applications during the current checkpoint period are not reflected by ReplFindNextChange or ReplGetOidStatus. In other words, the data that a synchronization client computer reads will always be between two checkpoints, and setting a new checkpoint will move the range of changes that it reads.
For example, suppose that a synchronization client computer opens a new synchronization session. The changes that it will read will be the changes that occurred up to the point its session was opened. In that manner, the first time the session opens is the first checkpoint for that client, checkpoint #1. After it has read the data up to that point, it checkpoints again, checkpoint #2. Now if it reads again it will get all changes that were made by other applications between checkpoint #1 and checkpoint #2. If no changes were made, ReplFindNextChange and ReplGetOidStatus will not find any modified items. Opening or closing the session will not cause any further checkpointing. After the session is first opened, all checkpoints are signaled by ReplCheckpoint. The current checkpoint and other information are saved in the synchronization state.
A final detail of count-based replication is that it tracks items not by their object identifiers, but by a search identifier that can be obtained from the object identifier using GetOidSearchID. Like an object identifier, the search identifier is unique within a single volume or within the object store, but not across volumes. However, a search identifier is recycled among objects that are deleted while an object identifier is not recycled for 16 deletions. Therefore, a synchronization client computer will need to track items by their search identifiers but examine their object identifiers to determine whether an object was deleted and recreated.
See Also
Send Feedback on this topic to the authors