[Akonadi] [Bug 322083] New: CollectionSync always start a database transaction, even when no update needs to be done

[Alessandro Pignotti]

https://bugs.kde.org/show_bug.cgi?id=322083

            Bug ID: 322083
           Summary: CollectionSync always start a database transaction,
                    even when no update needs to be done
    Classification: Unclassified
           Product: Akonadi
           Version: unspecified
          Platform: Ubuntu Packages
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: kdepim-bugs at kde.org
          Reporter: alexpigna.dev at gmail.com

Disclaimer: I'm not expert in akonadi codebase, so the terminology might not be
100% correct.

CollectionSync derives from TransactionSequence, which means that all the Jobs
added are wrapped in a database transaction. This probably make sense to
guarantee correctness in case of concurrent updates.

The problem is that a transaction is started even in the case when no updates
needs to be made. The effect of this is that mysql (when it is the backend) is
no longer able to optimize the load of the local collection data and needs to
write book-keeping data on the log. This means that in the very frequent case
of no updates needed (so, theoretically read only operation) mysqld will still
be writing to disk, with an effect on system performance and battery usage.

I'm not sure what could be a good solution to this problem, my guess is that it
could make sense to operate in two phases:

1) Load the local collection without starting a transaction and compare with
the remote one to see if anything needs to be updated

2) If needed, start a transaction and do the complete sync. This will cause
overhead when updates are needed, but hopefully this is balanced by the
optimization of the read only case.

I think another possible solution would be to use explicit table locks, but
akonadi currently seems to have no concept of locking.

Reproducible: Always

Steps to Reproduce:
1. Add an IMAP resource that is polled regularly
2. Watch akonadi mysqld process with strace, grep for 'pwrite'

Actual Results:  
I can see write operations happening when apparently no new mails are arriving

Expected Results:  
Read only operations should be read-only

-- 
You are receiving this mail because:
You are the assignee for the bug.