doc/bugs/locking_fun.mdwn

   1 It's possible for concurrent web edits to race and the winner commits both
   2 changes at once with its commit message (see r2779). The loser gets a
   3 message that there were conflicts and gets to see his own edits as the
   4 conflicting edits he's supposed to resolve.
   5
   6 This can happen because CGI.pm writes the change, then drops the lock
   7 before calling rcs_commit. It can't keep the lock because the commit hook
   8 needs to be able to lock.
   9
  10 Using a shared reader lock plus an exclusive writer lock would seem to
  11 allow getting around this. The CGI would need the exclusive lock when
  12 editing the WC, then it could drop/convert that to the reader lock, keep
  13 the lock open, and lauch the post-commit hook, which would use the reader
  14 lock.
  15
  16 One problem with the reader/writer idea is that the post-commit hook writes
  17 wiki state.
  18
  19 An alternative approach might be setting a flag that prevents the
  20 post-commit hook from doing anything, and keeping the lock. Then the CGI
  21 would do the render & etc that the post-commit hook normally does.