We have at least three mail protocols now which are delta-based. That
is, you have a bookmark, 'sync key' or timestamp which represents what
the server *last* told you about a given folder. You say to the server
"what changed since XXX", and get back a list of added/removed/changed
messages along with a *new* timestamp YYY.
It's a very efficient way to handle mailbox access, and it's used by at
least ActiveSync, EWS and IMAP+QRESYNC. In the Exchange protocols it's
called 'SyncState' or 'SyncKey', and in IMAP it's the HIGHESTMODSEQ.
(It's never *actually* a timestamp, since wall-clock time is a PITA. But
it's easy to *think* of it as as timestamp; the modification time on the
folder).
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).
I'm not sure how to fix it. Looking at EWS first, since that's where we
noticed it, I pondered removing the camel_folder_summary_save_to_db()
call from the camel_ews_utils_sync_{created,updated,deleted}_items()
helper functions, so it happens just *once* at the end of the loop in
ews_refresh_info_sync() and commits all the changes at once. But just
deferring the camel_folder_summary bits isn't enough, is it? The
individual message_infos will have a lifetime of their own, and even
*internally*, camel_folder_summary_save_to_db() doesn't actually write
things out atomically using transactions in sqlite... does it?
Any suggestions or insight would be gratefully received...
--
dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature