Change Details

If two threads (TA and TB) would call retrieveByNameOrCreate() with a *different* argument (say A and B), TA might acquire the lock to create A, and meanwhile TB will fail the tryLock() and never create B. Also the final lock/unlock (with nothing in between) was useless. Solution: lock around lookup+creation, don't use tryLock (which is almost always wrong IMHO...), simplify code by using QMutexLocker. I found this by reading the code, but indirectly this seems to also fix akonadiserver locking up in mysql queries during akonaditest startup (sometimes), probably because it reduces concurrent querying a bit...

If two threads (TA and TB) would call retrieveByNameOrCreate() with a *different* argument (say A and B), TA might acquire the lock to create A, and meanwhile TB will fail the tryLock() and never create B. Solution: lock around lookup+creation, don't use tryLock, simplify code by using QMutexLocker. I found this by reading the code, but indirectly this seems to also fix akonadiserver locking up in mysql queries during akonaditest startup (sometimes), probably because it reduces concurrent querying a bit...

If two threads (TA and TB) would call retrieveByNameOrCreate() with a *different* argument (say A and B), TA might acquire the lock to create A, and meanwhile TB will fail the tryLock() and never create B. Also the final lock/unlock (with nothing in between) was useless. Solution: lock around lookup+creation, don't use tryLock (which is almost always wrong IMHO...), simplify code by using QMutexLocker. I found this by reading the code, but indirectly this seems to also fix akonadiserver locking up in mysql queries during akonaditest startup (sometimes), probably because it reduces concurrent querying a bit...