Browse Source
In a server scenario such as Gerrit Code Review, there may be many atomic BatchRefUpdates contending for locks on both the packed-refs file and some subset of loose refs. We already retry lock acquisition to improve this situation slightly, but we can do better by using an in-process lock. This way, instead of retrying and potentially exceeding their timeout, different threads sharing the same Repository instance can wait on a fair lock without having to touch the disk lock. Since a server is probably already using RepositoryCache anyway, there is a high likelihood of reusing the Repository instance. Change-Id: If5dd1dc58f0ce62f26131fd5965a0e21a80e8bd3stable-4.9
Dave Borowitz
7 years ago
3 changed files with 173 additions and 87 deletions
Loading…
Reference in new issue