GNOME Bugzilla – Bug 652659
Support bulk-commits of property changes to Personas
Last modified: 2018-08-04 08:27:14 UTC
Commits can be implemented using Persona.freeze_updates()/Persona.thaw_updates() on a per-persona level. If a persona isn't frozen, all property updates are committed individually as before.
Punting bugs that won't be fixed by Folks 0.6.0.
See also: ideas in bug #657510.
This is similar to bug #684766: the entity reacting to changes performs better if it knows that a sequence of changes are happening and when the sequence ends. In #684766, it is SyncEvolution which wants to avoid generating more of its D-Bus "individual changed" signals than necessary. In this issue it is the PersonaStore or more specifically, the EDS backend, which should better only issue one update to the underlying database instead of one per property change. Perhaps a kind of "flush" signal would work for FolksPersona as well as the FolksIndividualAggregator?
I noticed that making many property changes quickly leads to a deadlock in evolution-contact-factory. What happens is that each property change triggers a separate EDS modify_contact call. They overlap in time, so that evolution-contact-factory starts processing them in parallel in multiple threads. A stack backtrace shows that these threads then deadlock on a mutex, deep inside libdb. Of course this is a bug in EDS and/or libdb. However, this points to another problem: is it guaranteed that EDS processes requests in order? I don't think the EDS API makes such a guarantee. If requests get reordered, an older request overwrites the data written by a more recent one, thus leading to the wrong result. IMHO folks should delay sending more modify_contact requests for the same contact until the previous request has completed. That will have the side effect of automatically batching several (but not all) property changes in the same request. Optional: delay sending the first request until the process is idle. That would have the effect that (at least for SyncEvolution) only a single request would be sent, as intended. I don't know about vala's support for asynchronous method calls to implement this. Can someone else take a shot at this? It's fairly urgent, because I wanted to have contact modification working (reliably :-) end of this week.
As discussed on IRC, the lack of explicitly mentioned support for concurrent change_* methods implies that a client cannot assume that this will work. IMHO it is reasonable to expect it to work (no batch API for changes, folks could detect concurrent changes and correctly serialize/combine them). Until it does, I'll serialize requests inside SyncEvolution.
(In reply to comment #5) > Until it does, I'll serialize requests inside SyncEvolution. I've implemented that, but its really messy. Not only does it write way too often into EDS, each change also triggers a change notification from EDS to folks and thus an updating of the FolksIndividual that I am working with. The classes above FolksIndividual and the client using my API also get way too many change notifications.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/folks/issues/19.