diff options
author | joey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071> | 2007-02-21 01:13:30 +0000 |
---|---|---|
committer | joey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071> | 2007-02-21 01:13:30 +0000 |
commit | 1c7cdc5760f4096103cdb0fd99bee029bf8bc947 (patch) | |
tree | 38734fc149a5ea6fa126960bb03f0b8dace80513 | |
parent | b157754e994b46aacf5f34a1d87140a6e4acf121 (diff) | |
download | ikiwiki-1c7cdc5760f4096103cdb0fd99bee029bf8bc947.tar ikiwiki-1c7cdc5760f4096103cdb0fd99bee029bf8bc947.tar.gz |
locking bug
-rw-r--r-- | doc/bugs/locking_fun.mdwn | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/doc/bugs/locking_fun.mdwn b/doc/bugs/locking_fun.mdwn new file mode 100644 index 000000000..8c4e0690b --- /dev/null +++ b/doc/bugs/locking_fun.mdwn @@ -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. |