Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

[Chenthill <pchenthill novell com>]

On Thu, 2009-01-08 at 10:49 +0100, Patrick Ohly wrote:
> On Thu, 2009-01-08 at 10:10 +0530, Suman Manjunath wrote:
> > On Wed, Jan 7, 2009 at 17:15, Patrick Ohly <patrick ohly gmx de> wrote:
> > > The plan for change tracking is to get rid of the dependency on
> > > e_book_get_changes(). I already stopped using e_cal_get_changes()
> > > because it was too inflexible. Instead I'll rely on the REV resp.
> > > LAST-MODIFIED properties: the backend must update these each time an
> > > item is modified. This seems to be supported by most backends. Are there
> > > backends which are known to not support this?
> > 
> > a) Looking at [1], I can't find what a REV property is. Did you mean
> > to use [2] ?
> 
> REV is part of vCard 3.0. It would be used in ebook. ecal would use
> LAST-MODIFIED instead. Does the GroupWise server update REV when
> contacts are modified?
> 
> > > The problem with concurrent modifications is two-fold.
> > > Stale data in UI:
> > >      * user opens an item in Evolution
> > >      * synchronization starts in the background
> > >      * updates the item in EDS
> > >      * => When the user saves his changes, will he overwrite the more
> > >        recent data in EDS? Will he be warned? With Evolution the user
> > >        is not warned and his changes overwrite the ones in EDS (tested
> > >        with contacts). Evolution should listen for change signals and
> > >        warn the user as soon as he has stale data in the edit dialog.
> > >        The user then can cancel and reopen the item to redo his
> > >        changes. This is unlikely to happen often, so more elaborate
> > >        solutions (merging changes, additional buttons to copy from EDS)
> > >        should not be necessary. Should I file a bug for this? Anyone
> > >        able and willing to work on it?
> > 
> > Not so for calendars.
> 
> I only tested with a contact. There the problem occurs as described
> above.

As suman had mentioned, this is not a problem for calendar as the
modifications are notified to the UI by matching the live queries in
place.

> 
> > > Stale data in sync:
> > >      * when the sync starts, it builds a list of new/updated/deleted
> > >        items
> > >      * user modifies data in EDS
> > >      * this leads to conflicts, f.i. sync modifies item that was
> > >        modified by user
> > >
> > > Both cases need to be handled by the program which wants to make changes
> > > to EDS data (Evolution, sync engine). To avoid race conditions, support
> > > by EDS would be needed which currently doesn't exist. As a workaround
> > > the following method would reduce the time window in which conflicts can
> > > occur:
> > >      * get revstring before starting to make modifications (when
> > >        opening item in UI; when starting sync)
> > >      * before modifying the item, check the revstring again
> > >      * if the same as before, do the modification
> > >      * if different, handle conflict
> > 
> > The GroupWise server updates the 'modified' property of the item when
> > it actually gets modified on the server. For newly created items, it
> > also adds the 'created' property at the same time.
> > 
> > This behavior invalidates all the 'handle-at-backend' approaches to
> > fix the apparent bug,
> 
> "the apparent bug" =
> https://bugzilla.novell.com/show_bug.cgi?id=184554 ?
> 
> Or do you mean the problem with overwriting more recent changes?
> 
> I'm not sure I understood how the GroupWise server and backend work.
> What you are saying is that locally cached data might get out of sync
> with the server and thus checks in the Evolution backend cannot be
> implemented 100% accurately, right?
> 
> That sounds like a real problem, but I still see room for improvement.
> For example, the backend could implement the workaround that I described
> in my email. A client can't do that because without changes in the
> backend it might read stale data, compare successfully, then push an
> update which overwrites modifications on the server.
> 
> > > A secure solution would have to put the revision check into EDS itself
> > > to make the check and update atomic. The proposal is to add this check
> > > to e_book_commit_contact() and e_cal_modify_object():
> > >      * The caller is expected to include REV resp. LAST-MODIFIED as
> > >        read from EDS earlier.
> > >      * The EDS backend compares against the current value before
> > >        updating the item. If there is a mismatch, the update is
> > >        rejected with a suitable error code.
> > >      * If the values are unset, the update is always executed.
> > 
> > A backend may not have a LAST-MODIFIED property for a particular event
> > in this use case:
> > a) create a new appointment in the GW calendar (while online)
> > b) open the same appointment (before the refresh timeout)
> 
> That's because the local copy of the appointment is not identical to the
> one on the server, right? Perhaps the backend could force an immediate
> refresh of this particular appointment to get the server's
> LAST-MODIFIED?
You are right. This is a problem in groupwise backend and not common to
all backends. We should be storing the last modified time stored in
server as soon as the item is created. There is a problem in the
groupwise soap interface that it does not return the
created/last-modified time stored on server after creating the item. May
be the item has to be fetched again to get these fields. But this is a
problem only to groupwise and should be fixed in the backend.


thanks, Chenthill.