Akonadiserver: rework handling of database deadlocks.

Authored by dfaure on Apr 7 2019, 7:50 AM.

Description

Akonadiserver: rework handling of database deadlocks.

Summary:
We can't just replay the SQL commands, that's too low-level: if we do
INSERT, then use the resulting ID into e.g. another INSERT command, at replay
time we might get a different ID from the first command, and then insert
the wrong ID in the second one...

So instead we want to re-run the entire handler's parseStream(), which we
do by throwing a DbDeadlockException (from QueryBuilder), and catching that
in the caller (Connection) using a helper class (DbDeadlockCatcher, unittested)
which retries up to 5 times.

For this to work, it means:

  • we must also rollback any chances made to in-memory caches (done by

clearing those caches, good enough since DB deadlocks are rare)

  • ItemModifyJob which sends parts on demand, shouldn't delete after

sending (it might be asked again) -- this was hit by GidTest (fetchAndSetGid).

Still TODO:

  • delaying the updating of intervalChecker and cacheCleaner by NotificationCollector until commit time;
  • checking other users of QueryBuilder (who now can get a DbDeadlockException...)

Test Plan:
all this was triggered by a unittest that creates 10 sessions
and adds 10 different attributes to the same time, one in each session. This very
often hits the DB deadlock scenario.

Reviewers: dvratil, vkrause

Reviewed By: dvratil

Subscribers: kde-pim

Tags: KDE PIM

Differential Revision: https://phabricator.kde.org/D20326

Details

Committed
dfaureApr 7 2019, 10:54 AM
Reviewer
dvratil
Differential Revision
D20326: Akonadiserver: rework handling of database deadlocks.
Parents
R165:3e2cf23f434b: Merge remote-tracking branch 'origin/Applications/19.04'
Branches
Unknown
Tags
Unknown