|
Any PDA device, whether it is a Palm, Pocket PC, WinCE, Psion,
EPOC or some other variant, manipulates data internally. These
devices are battery powered, as is their memory. If the batteries
die, the memory is cleared and all the data entered is lost. To
remedy this, there must be some way to back up the data. In most
circumstances, this will be to a local desktop database held on a
PC.
This local data is rarely simply stored. It is invariably
accessed by a local application that will allow you to change the
data. Therefore, we have a scenario where data is stored in two
different physical locations (the PDA and the desktop) and is
capable of being changed in either place.
The method, by which we use data from both these places to
produce one simple, consolidated database that is then copied to
both locations, is known as synchronization.
On the face of it, synchronization merely merges two databases
to give a single, consolidated database. In practice, this proves
to be fairly complex. For example:
You meet a friend after work and they tell you that they have
moved. They give you their new address and you update your PDA with
this information, changing the address to read 1243 The High
Street. A few days later (without having synchronized your PDA),
your friend calls you at the office to tell you that he gave you
the address incorrectly. You update the desktop data with the
correct address, 1234 The High Street.
What happens when you come to synchronize your data? We know
what we'd like to happen, but what actually happens? The following
table describes how Palm handles conflict resolution:
 |
 |
 |
 |
 |
Archive the handheld record then delete from handheld and desktop |
 |
|
Delete from handheld and desktop |
 |
|
Update desktop record |
 |
|
Insert handheld record to desktop db |
|
|
Archive the desktop record and delete from handheld and desktop |
|
|
Delete from handheld and desktop |
|
|
Update handheld record |
|
|
Insert record to handheld |
|
|
If both changes are the same, nothing happens. If they are different, a new record is added to the handheld (from the desktop) and a new record is added to the desktop (from the handheld). In other words, an extra record is added. |
|
|
The updated record is copied to the handheld |
|
|
The updated record is copied to the desktop |
|
|
Archive the handheld record and update handheld record from the desktop record |
|
|
Archive the desktop record and update the desktop record from the handheld record |
|
|
Archive the handheld record then delete from desktop and handheld |
|
|
Archive the desktop record then delete from desktop and handheld |
|
|
Add to archived database |
|
|
If both changes are the same, archive both the handheld and desktop records. If not, do not archive the handheld record but add the desktop record to the handheld and add the handheld to the desktop |
|
|
Do not archive the handheld record. Instead, replace that record with the desktop record |
|
|
Archive handheld if changes are the same then delete from both. Otherwise, do not archive the desktop but add the desktop record to the handheld and the handheld record to the desktop |
|
|
Do not archive the desktop but replace the desktop record with the handheld record |
Note that not all circumstances are identified, merely ones that
may require resolution. For example, we do not show what would
happen if a record were inserted at the PDA and a record were
inserted at the desktop, as it is clear to see that the PDA record
will be added to the desktop and vice-versa.
This table is complete, in that it discusses archived records as
well (an audit feature, if you will). This appears to complicate
the issue but, for now, examine the situation where both the
handheld and the desktop records are updated, and ignore all
references to archive.
To answer our original question, we see that Palm has adopted a
scheme whereby data is never lost. In fact, it will duplicate data
rather than face the option of possibly deleting data that should
not have been deleted. In our case, we now have two records for our
friend. One has the correct address and the other has the incorrect
address. But which is which? We have to rely on memory and delete
the one that we think is wrong. Clearly, this is not the perfect
situation.
In the circumstance above, it would have been preferable to have
the desktop record overwrite the handheld record. Of course, this
may not always be the case. Sometimes, it would be better to have
the handheld record overwrite the desktop record. In both cases, it
would probably be preferable to have the record that was changed
last take precedence.
Currently, the Palm databases have no way of time stamping
records to deduce which was added last. On top of that comes the
question of time stored on the Palm and time stored on the desktop.
If there is a discrepancy between those times, which takes
precedence?
It should be becoming clear that a synchronization policy is set
in place by establishing rules on what should be done with data
under a given circumstance.
By examining the table above, we can also foresee other problems
that may arise. For example:
There are a number of incidents where we would store two copies
of a record to an archive. This contention should be reduced.
It is wholly possible to have two persons in the address book
that share exactly the same details. This being the case, if you
update one of those records, how would the HotSync process know
which record to update? One, the other, or both?
We may also be able to see room for improvement. For example,
synchronization is an 'all or nothing' approach. Might it
occasionally be preferable to limit both the rows and columns that
are considered for synchronization?
This introduces us to some of the complexities that industrial
grade synchronization and replication methods have to solve.
|
