https://bugs.kde.org/show_bug.cgi?id=338658
--- Comment #127 from Matthias Kretz <kr...@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 watching all bug changes.
