[Kde-pim] Syncronization issue with Akonadi

Stephen Kelly steveire at gmail.com
Fri Jan 2 13:43:09 GMT 2009


Volker Krause wrote:

> On Thursday 01 January 2009 17:13:20 Stephen Kelly wrote:
>> Volker Krause wrote:
>> > The Akonadi server provides conflict detection, in your example that
>> > means the application would ignore the change notification would just
>> > try to write its own changes. Akonadi detects that using the item
>> > revision number but leaves handling that case entirely to the client.
>>
>> Hmm, I understand what you mean about akonadi detecting conflicts, but I
>> don't see any way for it to report a conflict to the application. If the
>> application is going to handle the conflict, it has to either be told
>> about it, or not ignore the change notification, right?
> 
> In case of a conflict (revision number on the server differs from the one
> used by the client), the ItemModifyJob fails with a corresponding error.
> That's all the reporting that happens from the Akonadi side. The
> application that tried to store the change then has to handle this case,
> eg. it could fetch the new version from the server and show a merge dialog
> for the two ones.
> 
> Note that this is independent of ignoring change notifications, even when
> listing to them there is a small time window between receiving the
> notification and storing your changes where you still could run into this.
> Also, a change notification while editing an item probably needs the same
> kind of conflict resolution, it's just detected earlier.

OK, that's all clear now. I'm keeping notes of this in the extended apidox
I'm writing in kjotsrewrite/akonadi_next.

However, I did think of another conflict situation. The above one depends on
a race condition when akonadi already knows about a change in an item a
user is editing, but I think this one is a bit different.

Imagine Alice is out of office for the day, and while disconnected, she
updates an address as above. Meanwhile, Bob is still in the office and he
changes the address to, as above. Revision numbers match up, so there is no
conflict.

When Alice gets connectivity back, two things will happen. Her akonadi
server will get notified that the address has changed, and her resource
will notify the groupware system that she has updated the address of the
contact. The order that those two things will determine what happens. If
she retrieves changes from the groupware system first, her changes will be
overwritten (unless the revision number can help there too?). If her
resource notifies the groupware system first, Bobs changes there will be
overwritten.

This could happen while neither Alice nor Bob have any kind of address book
system open, so no application would necessarily be able to notify either
user even it is possible. I think the conflict would be silent though. To
the Akonadi servers on both Alice and Bobs machines, everything is
happening as expected. 

Is this a plausible scenario?

regards,

Steve.

>
> regards
> Volker


_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list