Hi Angela, this mail just to say i was wrong at my first analysis to incriminate persistence, looks like i was using isMember before adding a user to a group which is #1 useless, and #2 more & more expensive as i was adding users to group.
Nicolas > On 06 Aug 2015, at 10:56, Angela Schreiber <anch...@adobe.com> wrote: > > hi nicolas > >>> i am not too familiar with the sync mechanism... but looking just >>> quickly at the code it seems that it persists the sync of each >>> user/group. >>> that looks reasonable to me (even if it comes with some Root.commit() >>> overhead) as it allows to specifically retry or revert the changes >>> made during the sync of one single account. that's the defensive >>> way of minimising the unexpected behaviour for the consumer in case >>> of failure. >>> >>> on the other hand you might argue that the default should be success >>> and that in those cases less frequent calls to persist the changes >>> might work as well and was probably faster. >> mmm interesting, yeah i might argue that :-) > > :-) > >> and that we could probably in case of an error ³replay² user/group sync >> persisting one by one, >> from the last successful save. Will have a look. > > i don't think this is feasible. you will have to revert everything > again and start over again. in particular merge conflicts will be > impossible to sort out once you get them with a lot of different > changes made. > > but anyway: there is always a balance to find and i am not familiar > with those very design details in the sync handler... i am just reading the > code and trying to explain. for sure tobi provide more insight here. > > kind regards > angela > >> >> Thanks a lot, >> Nicolas >