<table><tr><td style="">dfaure created this revision.<br />dfaure added reviewers: dvratil, vkrause.<br />Herald added a project: KDE PIM.<br />dfaure requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D20326">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>We can't just replay the SQL commands, that's too low-level: if we do<br />
INSERT, then use the resulting ID into e.g. another INSERT command, at replay<br />
time we might get a different ID from the first command, and then insert<br />
the wrong ID in the second one...</p>

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

<p>For this to work, it means:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">we must also rollback any chances made to in-memory caches (done by</li>
</ul>

<p>clearing those caches, good enough since DB deadlocks are rare)</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">ItemModifyJob which sends parts on demand, shouldn't delete after</li>
</ul>

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

<p>Still TODO:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">delaying the updating of intervalChecker and cacheCleaner by NotificationCollector until commit time;</li>
<li class="remarkup-list-item">checking other users of QueryBuilder (who now can get a DbDeadlockException...)</li>
</ul></div></div><br /><div><strong>TEST PLAN</strong><div><p>all this was triggered by a unittest that creates 10 sessions<br />
and adds 10 different attributes to the same time, one in each session. This very<br />
often hits the DB deadlock scenario.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R165 Akonadi </div></div></div><br /><div><strong>BRANCH</strong><div><div>master</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D20326">https://phabricator.kde.org/D20326</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>autotests/libs/itemstoretest.cpp<br />
autotests/libs/itemstoretest.h<br />
autotests/server/CMakeLists.txt<br />
autotests/server/dbdeadlockcatchertest.cpp<br />
src/core/jobs/itemmodifyjob.cpp<br />
src/server/connection.cpp<br />
src/server/connection.h<br />
src/server/storage/datastore.cpp<br />
src/server/storage/datastore.h<br />
src/server/storage/dbdeadlockcatcher.h<br />
src/server/storage/dbexception.cpp<br />
src/server/storage/dbexception.h<br />
src/server/storage/querybuilder.cpp<br />
src/server/storage/querybuilder.h<br />
src/server/storage/transaction.cpp</div></div></div><br /><div><strong>To: </strong>dfaure, dvratil, vkrause<br /><strong>Cc: </strong>kde-pim, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil<br /></div>