[Kolab-devel] About conflicts and the sync concept (Re: Kolab Webservice initiative)

[Hendrik Helwich]

Hello Bernhard,

Am Mittwoch, 16. November 2011 11:34:06 schrieb Bernhard Reiter:
> [..]
>
> > What should be addressed here are concurrency conflicts when different
> > clients are reading/writing the same data at the same time. This type of
> > conflicts can be avoided by implementing a transaction concept.
> > A simple example is when client A updates a contact X and client B reads
> > contact X at the same time. The update is done in two steps (delete &
> > create) and it can happen that this contact gets deleted from client B
> > even if it is logically never deleted from the server at all. If it is
> > done the other way round you could get duplicates on client B depending
> > on how the Kolab clients are implemented.
>
> We already have a "transaction concept", it says that you should
> create first and then delete. If the connection is interrupted
> after create, there are two or more objects with the same id for all

you also can have duplicates on the server if two clients are updating the 
same item on the server concurrently and didn't notice the conflict because 
of that.

> clients. And all clients need to be able to resolve this situation
> because they need to do this anyway if two people edit the same object.

I agree that for the synchronization conflicts every Kolab client needs to 
have a strategy how this should be solved (e.g. server wins).
But it can also happen that on the Kolab server there are more than one item 
with the same ID (e.g. by two clients updating an item concurrently or an 
error occurs while a client is updating an item).
A Kolab client needs to have also a strategy for this case (e.g. take highest 
UID). This is an example of the addressed concurrency conflicts which could 
be avoided with a transaction concept that supports isolation.

> Often only a human an decide this interactively, this is a reason why all
> Kolab client SHOULD have a way to interact with the user.

Unfortunately this is not possible for all clients. E.g. the Syncphony project 
(uses Kolab WS) has not the possibility to show a dialog on the many 
supported mobile phones.
This is the same for the evolution-kolab project where also only a background 
service is adapted which has not the possibility to open a dialog in th GUI 
application.

> > Maybe the point would be more clear if it is extended that this does not
> > solve typical important synchronization conflicts due to cached data?
>
> That would be helpful of course as it makes the aim clear.
> I am not sure that the clarified aim can be reached, though.

Why?

> > > The IMAP transaction design by Martin was suited to the situation that
> > > the clients will have to deal with two or more objects for the same
> > > entry due to the unavoidable concurrent writing access. So it is
> > > perfectly fine, self healing and does not need to more "more atomic" as
> > > far as I can say. ;)
> >
> > Maybe i have skipped this part in the Kolab documentation? Do you know
> > where this information can be found on the Kolab page?
>
> I hope it is documented as this concept is rather old and makes sense,
> but I also could not find it right away. So I'm not sure this special Kolab
> twist of the IMAP disconnect mode is fully documented.

This information could be very helpful for Kolab client developers.

Best regards,
Hendrik

> Martin, do you remember where you have documented this part of the concept?
> I think you also had a sync queue concept and I also wonder if you remember
> writing this down or not. I still remember both concept and discussion them
> with you. And they are great concepts!
>
> Best,
> Bernhard