Re: [Evolution-hackers] RFClue: Atomic folder updates

[Milan Crha <mcrha redhat com>]

On Sat, 2011-12-03 at 00:05 +0000, David Woodhouse wrote:
> The problem is, we need to handle these updates *atomically*. If we
> store the new timestamp before the changed messages, and we crash in
> the
> middle of doing so, then we might miss out forever on the messages in
> question. We'd restart, go to the server and say "what happened since
> YYY" and we never get told *again* about the messages which came in
> between time XXX and time YYY, that we didn't manage to fetch.
> 
> And if you do it the other way round and store the changed messages
> first, and crash before you store the new timestamp, you get similar
> issues (cf. bug 664637).

	Hi,
I do not think you can do anything on the CamelFolderSummary side
itself, except of changing your descendant of CamelMessageInfo, but
there still be time intervals where crash or unexpected interruption
will cause issues. I'm not sure if it's understood from your
description, but the SyncKey on the exchange server changes as soon as
the Sync call is finished (the server returns the new key), and asking
with the old key results in this "bug". So, you could do:
 a) Call Sync With the XXX key
 b) process result with returned YYY key in a way:
    - mark CamelMessageInfo-s which changed as changed (to be updated)
    - create fake info-s with the same flag as above for new items
    - delete those deleted
 c) save changes to disk with the new YYY Sync key
 d) update what is supposed to be updated

There still is a chance that you crash during b), though that all is
supposed to be done on a local machine only, thus should not take that
long (depends on folder size and such).

You may check on folder open whether there are any info-s marked for
update and process d) if yes, and only then continue with the stored
sync key.

I guess something like that should work. I do not see how any atomicity
would help you here, because when any trouble happens between
SyncFolderItems call and saving of all received changes with the new
Sync key will always result in a desync between either key stored
locally and on the server or the folder content not being updated fully.

Nonetheless, there are people whom are willing to connect to their
exchange account from multiple machines. Did you try whether this sync
can work in such environment, please? I didn't, but I will be surprised
if the Sync key is distributed per client, as it seems like a
memory-consuming operation on the server for me. Imagine two identical
installations with identical evolution-ews versions in use, only on two
different machines connecting to the same server with the same user
name. You might get out of sync with the Sync keys in such environment
quite easily.
	Bye,
	Milan