Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Race condition in updatePage? #180

Open
jgm opened this Issue · 2 comments

1 participant

@jgm
Owner
jgm commented
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
Owner
jgm commented

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 jgm was assigned
@jgm
Owner
jgm commented

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
Something went wrong with that request. Please try again.