Re: [Evolution-hackers] API considerations for avoiding data loss in race conditions

[Milan Crha <mcrha redhat com>]

On Thu, 2012-12-06 at 10:43 -0500, Matthew Barnes wrote:
> On Thu, 2012-12-06 at 16:22 +0100, Christian Hilberg wrote:
> > * EClient starts transaction / acquires lock on PIM
> >   entry
> > 
> > * E-D-S records transaction start / gives away the PIM
> >   entry lock to the EClient requesting
> > 
> > * EClient dies for any reason
> > 
> > * Started transaction / aquired PIM lock persists in
> >   E-D-S
> > 
> > What now? Timeout after some time? Welcome back to possible
> > raciness (-->does not truly solve our problem).
> 
> This scenario is easily handled by watching the bus name of the client
> process that acquired the lock.  If the bus name vanishes, release the
> lock immediately.
> 
> But we have no such transaction lock at present, do we?

	Hi,
nope, there is no such API for it, and I do not think it's of any use
when you consider the eds<->groupware server case. From my point of view
the client should take care of the potential issues when
modifying/removing the contact/event/....

When you look at it then the chain is:
   EClient <-> eds backend <-> remote server

The EClient is a client for the eds backend.
The eds backend is a client for the remote server.
And you cannot expect remote servers running transaction locks on items
when any client decides to take one.

Evolution, as one of the EClient user, has capability of notifying user
about received changes, at least the calendar part component editor
notifies user when the item is opened and the view receives update of
it. And that's the way to go.

The connection between eds backend and remote server is harder, because
the backend cannot talk to user directly right now, but I'm working on a
service which will allow it, which should help too. Nonetheless, the
conflict strategy is currently chosen by each respective backend coder,
rather than left to a user.

That said, I would not go with the "transaction locking", it doesn't fix
much. I'd rather update book and calendar DBus/backend/EClient API to
include necessary parameters for conflict resolution (enum for conflict
resolution on modify and expected revision/last-modified for remove
operations), and the client should implement what to do, if it gets
Out-of-Sync error.

The best if there is some centralized place for conflict resolution,
thus the EClient users (and backends) will not need to duplicate the
code. Though that's probably another question, and a project on its own.
	Bye,
	Milan