<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/D19487">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>TransactionSequence was emitting result() twice when rolling back.</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">How did this happen?</li>
</ul>

<p>The TransactionRollbackJob is (automatically) added as a subjob of the<br />
TransactionSequence, so when it finishes, slotResult is called (like for<br />
all subjobs), as well as rollbackResult().<br />
Since the latter emits result() already [mostly for symmetry with<br />
commitResult()], we don't need to do that in slotResult (which doesn't do<br />
it for the case of committing, either).</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">Why is it a problem to emit result() twice?</li>
</ul>

<p>Well, first, it's against the law in KJob world. In practice,<br />
ItemSyncPrivate::slotTransactionResult was called twice (for the same<br />
TransactionSequence job) which made it decrement mTransactionJobs one<br />
time too many.<br />
As a result, checkDone() finished too early and didn't go into the<br />
"commit transaction" branch for other transactions.<br />
Leaving a transaction "open" is a good recipe for database deadlocks further<br />
down the line.</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">Why did the TransactionSequence roll back in the first place?</li>
</ul>

<p>In my case because of the infamous and not-yet fixed "Multiple merge<br />
candidates" problem, but it seems that it can also happen when having<br />
items without a part, according to Volker's investigations.<br />
All of these issues still need to be fixed, but at least akonadi seems<br />
to be still usable after they happen.</p>

<p>CCBUG: 399167</p></div></div><br /><div><strong>TEST PLAN</strong><div><p>Ctrl+L in kmail, with a folder having multiple items for the same RID</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R165 Akonadi </div></div></div><br /><div><strong>BRANCH</strong><div><div>Applications/18.12</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D19487">https://phabricator.kde.org/D19487</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>src/core/jobs/transactionsequence.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>