[Kde-pim] Review Request 117608: ItemSync: Fixed and tested transaction handling.

[Commit Hook]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117608/#review55965
-----------------------------------------------------------


This review has been submitted with commit d54a1b8b78bca5998ce91905b3d0faf285145b87 by Christian Mollekopf to branch master.

- Commit Hook


On April 17, 2014, 10:54 a.m., Christian Mollekopf wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117608/
> -----------------------------------------------------------
> 
> (Updated April 17, 2014, 10:54 a.m.)
> 
> 
> Review request for KDEPIM-Libraries and Dan Vrátil.
> 
> 
> Repository: kdepimlibs
> 
> 
> Description
> -------
> 
> ItemSync: Fixed and tested transaction handling.
> 
> The fetchjobs need to be part of the transaction as well, as they are otherwise
> not executed before the transactoin is complete.
> 
> ItemSync: Fixed single transaction mode, adapted test to trigger problem from last patch.
> 
> mTransactionJobs should not be checked here, as it is already checked in
> checkDone, and the check in proess is only valid when using
> 
> ItemSync: Fix full sync
> 
> Ensure that checkDone doesn't start the next batch while we're still fetching
> the items.
> This bug was triggered only if setFullSyncItems was called at least twice in streaming
> mode (therefore it only appeard on large imap folders where the items
> we delivered in two batches, and only during the flag sync which is a full sync).
> The first call triggered the ItemFetch, but while that was in progress,
> the second call went via process() to checkDone(), which cleared mProcessingBatch
> and immediately started a second parallel batch, and a third batch was started
> by deliveryDone(). This resulted in the first two batches (20 items), appearing as new
> (because the were processed before the local items were fetched), and the already locally
> available items getting deleted, because they couldn't be removed from
> mUnprocessedLocalIds (since they were processed before entering that list.
> 
> We use the job counter to lock, just like everywhere else.
> 
> 
> Diffs
> -----
> 
>   akonadi/itemsync.h 7dbba1d0408e4098a14ea6ff0eebc6696d310958 
>   akonadi/itemsync.cpp e1edae20ea41c8e8b2685e8fa9e015f0356eafef 
>   akonadi/tests/itemsynctest.cpp 84b9b10aefafbf9ed62303e81e062988a6380a7c 
> 
> Diff: https://git.reviewboard.kde.org/r/117608/diff/
> 
> 
> Testing
> -------
> 
> Only the unittests so far. I'll follow up with some manual testing.
> 
> 
> Thanks,
> 
> Christian Mollekopf
> 
>

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/