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

[Bernhard Reiter]

Am Tuesday, 15. November 2011 17:00:32 schrieb Hendrik Helwich:
> > > >   * No concurrency conflicts
> > > >   Conflicts if Kolab clients are accessing the Kolab server
> > > > concurrently can be avoided with the Kolab Webservice.
> > > >
> > > > I wonder how you are aiming to solve this one. When establishing the
> > > > Kolab concept it got clear that conflicts cannot be avoided from a
> > > > conceptual point of view. You would have to either give up scaling or
> > > > change the human nature. ;)
> > >
> > > The conflicts which are addressed here are that the IMAP server does
> > > not support transactions like a DBMS does. So if a layer like the Kolab
> > > WS is put on top of the Kolab server, it can add this feature to server
> > > operations which should be atomic but need more then one step. This can
> > > be used e.g. if you want to update a contact, which are two operations
> > > on the IMAP server (delete old mail, create new mail).
> > > This feature can only be enabled for clients who use the extra layer.
> > > For normal Kolab clients this would still be seen as multiple steps.
> >
> > You may be promissing to much then with the goal then. Your approach will
> > not eliminate the conflicts that cannot be avoided, e.g. when two people
> > edit the same contact or appointment concurrently at the same time.
>
> You are right there are important synchronization conflicts that cannot be
> avoided e.g. clients with an editable cache that is synchronized from time
> to time.

Especially with real offline support, which is a main design criteria
for the Kolab solution. ;)

> 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 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.
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.

> 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.

> > 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. 

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

-- 
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20111116/d28813c0/attachment.sig>