Synchronization is important for offline working. When working offline, changes on the datas are made but not updated in the main database. After beeing online again the client data should be synchronized with the server data. Conflicts may occurr when the same data have been changed at client site and server site.
Mobile synchronization also involves timeout and retry algorithms to handle interrupted communications.
The simplest method for synchronization is to+send all entries+to the other side. There they are matched to the existing entries to avoid duplicates. This is called+full sync+or slow sync. This type is+not very efficient+. However, this long during process cannot be avoided if the devices lost track of what has already been synchronized and what not.
*fast sync *
It is more efficient to only send modified items. For this purpose, changes must be detectable. On the server, this probably is a "last modified" timestamp. On the client, a simpler scheme often is used, the dirty bit. If a record is edited, it is set dirty. On synchronization, only dirty records are sent and after the termination of the communication, all dirty bits are removed. This type is called fast sync, as it is much more efficient. * *
Client and Server update the same (id) object
Client and Server insert objects with the same id
Client deletes an object that the server updates (and v.v.)
If both the server and the client record have been modified since last sync session, a conflict occurs. Some conflicts can be resolved automatically by merging the two items, others can't be solved and the user must be asked which version is the correct one.
To reliably identify items, unique identifiers are used. As sometimes identifiers are generated automatically client and server may assign different ID's to items. The client ID's are called local unique identifiers (LUID), as other clients are not known and could assign the same ID to an other item. The server has global unique identifiers (GUID). The server has to map between LUID and GUID for each device.
Open Mobile Alliance Data Synchronization and Device Management protocols (OMA DS and DM, formerly known as SyncML )
Funambol is also a software development platform for mobile applications. It provides client and server side Java APIs, and facilitates the development, deployment and management of any mobile project. Funambol is the de facto standard implementation of the Open Mobile Alliance Data Synchronization and Device Management protocols (OMA DS and DM, formerly known as SyncML ).
it keeps all the data available to it in sync. Under the hood, there is a "truth database" that is the final answer when it comes to deciding what data is up to date. Each application that wants to either share its data or look at another applicationâ€™s data subscribes to this truth database. When the application needs to change some data, its application notifies the truth database that the data has changed, and the database is responsible for notifying any and all other applications, devices, or machines that are interested in that piece of data.
Used also for online synchronization when working on the same data simultanously
Uses Push Data, Mingle Data, Pull Data, Commit Changes (an application can also "reject" a change)
- Databases / dataframeworks like Oracle LITE, IBM's DB2 Everyplace, Daffodil DB or Microsoft .NET Datasets may be used for holding of disconnected data. They have synchronizing mechansims/software included. Of these the Daffodil Replicator sounds most promissing as it is open souce and works with most RDBMS.
Daffodil Replicator supports bi-directional data synchronization, replication across heterogeneous databases, unlocking, security, conflict detectioin and resolution, partial replication, cyclic tables replication, large datatypes, scheduling, platform independent synchronization, debugging, it interacts with the internet.
Problem!!: probably it does not support oo-data.
Can SyncML be used on an oo-layer?
Is SyncML usable for large and dependent records?
Will applications that are online use the synchronization mechanism as well?
How can synchronization be implemented when updating of an object(record) leads to an insert as discussed for updates of objects that belong to more than 1 view?
Is it possible that a client holds only a section of the server data? How is this section defined?