summaryrefslogtreecommitdiff
path: root/server/src
diff options
context:
space:
mode:
authordrebs <drebs@leap.se>2016-07-31 18:25:48 -0300
committerdrebs <drebs@leap.se>2016-08-01 21:09:05 -0300
commit49cd07b909f2185b116bda5b30cfcfe0095291e0 (patch)
tree1686ada5eaa342db28f2f9384cfda7258ae65d1d /server/src
parent3b237bb46743a93feed4bb6f3c839d72fc28df48 (diff)
[bug] retry allocation of gen instead of using a lock
The use of a lock to allocate the next generation of a change in couch backend suffers from at least 2 problems: 1. all modification to the couch database would have to be made through a soledad server entrypoint, otherwise the lock would have no effect. 2. introducing a lock makes code uglier, harder to debug, and prone to undesired blocks. The solution implemented by this commit is not so elegant, but works for what we need right now. Now, concurrent threads updating the couch database will race for the allocation of a new generation, and retry when they fail to do so. There's no high risk of getting blocked for too much time in the while loop because (1) there's always one thread that wins (what makes the expected number of retries to be N/2 if N is the number of concurrent threads), and (2) the number of concurrent attempts to update the user database is limited by the number of devices syncing at the same time.
Diffstat (limited to 'server/src')
0 files changed, 0 insertions, 0 deletions