Race condition in updatePage? #180

jgm opened this Issue Jul 9, 2011 · 2 comments


None yet
1 participant

jgm commented Jul 9, 2011

What steps will reproduce the problem?
Haven't tried, because this is a theoretical problem that might be hard to
reproduce. If the same page is modified in two threads by updatePage, one
update might be overwritten by another in the working tree. Darcs and git
should correctly deal with two attempts to commit happening at the same
time, but the problem arises if the race condition occurs *before* darcs
record or git commit have been called.

I think basically you would need some kind of write lock. I think it might
as well be a wiki-wide single write lock, as I suspect darcs and git lock
the whole repository whenever they commit anyway.

Because the search function currently uses grep and therefore looks at the
working tree, I think the search will have to be locked as well during a
write lock. However, page views should not have to be locked, because they
use the revision control system rather than reading from the working tree,
so they should be unaffected.

What version of the product are you using? On what operating system?
Latest version from git

Google Code Info:
Issue #: 37
Author: gree...@gmail.com
Created On: 2009-03-10T16:45:25.000Z
Closed On: 

jgm commented Jul 9, 2011

I can confirm this. It happens on our setup regularly.

When two people (A and B) modify a page at the same time, the changes of A get committed under the name of B and B's changes disappear (or vice versa).

Google Code Info:
Author: joel.kaa...@gmail.com
Created On: 2010-06-15T07:54:03.000Z

jgm was assigned Jul 9, 2011


jgm commented Jul 9, 2011

Google Code Info:
Author: fiddloso...@gmail.com
Created On: 2010-06-15T13:50:33.000Z

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment