A couple of additional suggestions
martin.konold at erfrakon.de
Mon Aug 16 15:42:03 CEST 2004
Am Monday 16 August 2004 15:38 schrieb Stuart K. Bingë:
> How exactly is this currently handled, i.e. what happens when a
> disconnected client syncs, modifies an object, tries to sync again, and
> realises that the object was modified by another client between the two
The client shall first fetch all new messages/flags and then check its
"outgoing queue" for conflicts and act accordingly (e.g. conflict
A stupid client (allowed for now!) not beeing able to follow this procedure
leads to doubling of messages in case of conflicts.
These conflicts are then visible to the user and need manual resolution.
> I would think it should cancel the object edit/save, reload the (new)
> modified object, perhaps update the fields that were previously modified by
> the user before syncing (i.e. merge the newly loaded object and the
> user-edited object), and then resave after a user confirmation.
Yes, this is a possible client side conflict resolution mechanism. Though this
is not always that simple. E.g. the merge fails in case two clients modified
the same attribute at the same time.
> In this case the revision tag can work reliably. Unless this scenario that
> I described is totally off...
By definition we never have any lock! This leads to the fact that there is
always a window of opportunity that we miss an intermediate update.
Conclusion: The revision number works most of the time but is not reliable.
> There's a problem if the edited object no longer exists at the second sync,
> however. How is this case currently handled?
If the modified object got deleted in the meantime the same conflict
resolution rules apply. Deletetion is not different from modification in this
Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold at erfrakon.de
More information about the format