]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/commitdiff
locking bug
authorjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>
Wed, 21 Feb 2007 01:13:30 +0000 (01:13 +0000)
committerjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>
Wed, 21 Feb 2007 01:13:30 +0000 (01:13 +0000)
doc/bugs/locking_fun.mdwn [new file with mode: 0644]

diff --git a/doc/bugs/locking_fun.mdwn b/doc/bugs/locking_fun.mdwn
new file mode 100644 (file)
index 0000000..8c4e069
--- /dev/null
@@ -0,0 +1,21 @@
+It's possible for concurrent web edits to race and the winner commits both
+changes at once with its commit message (see r2779). The loser gets a
+message that there were conflicts and gets to see his own edits as the
+conflicting edits he's supposed to resolve.
+
+This can happen because CGI.pm writes the change, then drops the lock
+before calling rcs_commit. It can't keep the lock because the commit hook
+needs to be able to lock.
+
+Using a shared reader lock plus an exclusive writer lock would seem to
+allow getting around this. The CGI would need the exclusive lock when
+editing the WC, then it could drop/convert that to the reader lock, keep
+the lock open, and lauch the post-commit hook, which would use the reader
+lock.
+
+One problem with the reader/writer idea is that the post-commit hook writes
+wiki state.
+
+An alternative approach might be setting a flag that prevents the
+post-commit hook from doing anything, and keeping the lock. Then the CGI
+would do the render & etc that the post-commit hook normally does.