[Akonadi] [Bug 338658] GMail, Novell Groupwise, other IMAP: "Multiple merge candidates, aborting"

[Matthias Kretz]

https://bugs.kde.org/show_bug.cgi?id=338658

--- Comment #127 from Matthias Kretz <kretz at kde.org> ---
The fact that I can have an inconsistent state stored in my Akonadi DB is
telling. Apparently, while clients interact with Akonadi, the DB goes through
inconsistent states. Those appear to be open to races, and unfortunate
interrupts (crash, system hang, power loss).

What I'd do (and I'm guessing from a far away distance in the hopes it helps
inspire a real fix, hoping not to step on any toes):

1. Update the DB schema to enforce consistent state. In particular all foreign
keys need to be defined so that it's impossible to DELETE FROM parttable while
something in pimitemtable still holds a key to it.

2. Presumably this will break clients which rely on the DB to allow
inconsistent intermediate states. DB updates therefore need to be fixed to
atomically go from one consistent state to the next. E.g. use DELETE together
with INNER JOIN.

3. Races like "unread -> read -> unread" need to be guarded against via
compare-exchange atomic operations using some modification counter. E.g.
mailcheck create id=X, state=unread
kmail read id=X, state=unread
kmail write state=read WHERE id=X
mailcheck update id=X, state=unread (why would this happen anyway, can the IMAP
server indicate some update of metadata?)

If we add a version the UPDATE could be predicated on the version column still
storing the same value as when it was SELECTED before. E.g. the mail client
does
`UPDATE foo SET state=read WHERE id=X AND version=1` instead of `UPDATE foo SET
state=read WHERE id=X`. I actually expect Akonadi already has such a facility
and Allans guess is incorrect.

I have another guess from looking at my logs. I have lots of:

org.kde.pim.akonadiserver:   DB error:  "Lock wait timeout exceeded; try
restarting transaction"
org.kde.pim.akonadiserver:   Error text: "Lock wait timeout exceeded; try
restarting transaction QMYSQL3: Unable to execute statement"

I.e. KMail updates the UI to read state, tries to reflect the state change with
Akonadi, but the DB is locked up. The UPDATE fails, and the KMail UI reverts to
the state stored in Akonadi.

These locks might also be the reason why inconsistent entries in tables remain.
A first DELETE goes through, the second (to make it consistent again) times
out.

I have no clue where the locks come from though. One data point: After my
DELETE FROM statement above I've not seen a single DB error message about lock
timeouts again. Before I had lots.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.