Here's my understanding of the edit lock problem...
Whenever someone is actively in the process of writing their changes to disk, the software makes a temporary file (directory) on the disk to let other instances of the cgi process know that this one is doing some writing to disk. You don't want two processes to write to the same file at the same time, because you will lose one person's changes and possibly the entire file.
Notice that the edit lock is only there when you are *actively writing your changes to disk*. This isn't while you are typing them, but only for that instant after you hit 'submit' and before you get the next screen back.
The problem is that -- for mysterious reasons -- the script sometimes dies and leaves the edit lock hanging. All other processes after that refuse to write changes to disk because they think that someone has the edit lock.
There are several possible solutions. My own personal solution is wild. I just wouldn't use a lock at all. You run the risk of collisions, but these are so rare *in my experience* as to be worth ignoring.
Another solution is to have 'per-file' edit locks. This is more elegant, because there isn't any particular reason to lock the ENTIRE system down just because one person is writing to one file. If Larry is writing to file A and I am writing to file B, there is no reason to lock anything. The main downside to this solution is that it is still possible for an edit lock to get hung. The good thing is that only one page would be affected, not the entire site.
Another solution is to find the reason why the script is leaving the lock, and fix that bug. In my experience, this will be impossible. CGI scripts do in fact die for no apparent reason sometimes, and it's very hard to trap/debug/etc. I mean, it is theoretically possible, but as a practical matter I find that something is always left hanging.
One of my own personal design philosophies is that everything should fail gracefully. That is, I accept that my own software sucks and will in fact break. This is a matter of humility before the gods of software. The best that I can hope for is that when my software does choke, it will do so gracefully. There will always be bugs and things that don't work right, but as long as they don't destroy the universe, there's hope.
:-)
--Jimbo
Given your analysis, the idea of "per-file" edit locks sounds good to me. If that could be put together quickly, that would be great. But you don't sound quite sure that there's no significant risk if we were just to remove the edit locks altogether. I mean, what does a "collision" involve?
Larry
----- Original Message ----- From: "Jimmy Wales" jwales@bomis.com To: wikipedia-l@nupedia.com Sent: Friday, August 24, 2001 6:20 PM Subject: [Wikipedia-l] Edit locks
Here's my understanding of the edit lock problem...
Whenever someone is actively in the process of writing their changes to
disk,
the software makes a temporary file (directory) on the disk to let other
instances
of the cgi process know that this one is doing some writing to disk. You
don't
want two processes to write to the same file at the same time, because you
will
lose one person's changes and possibly the entire file.
Notice that the edit lock is only there when you are *actively writing
your changes
to disk*. This isn't while you are typing them, but only for that instant
after
you hit 'submit' and before you get the next screen back.
The problem is that -- for mysterious reasons -- the script sometimes dies
and leaves
the edit lock hanging. All other processes after that refuse to write
changes to disk
because they think that someone has the edit lock.
There are several possible solutions. My own personal solution is wild.
I just
wouldn't use a lock at all. You run the risk of collisions, but these are
so rare
*in my experience* as to be worth ignoring.
Another solution is to have 'per-file' edit locks. This is more elegant,
because
there isn't any particular reason to lock the ENTIRE system down just
because one
person is writing to one file. If Larry is writing to file A and I am
writing to file
B, there is no reason to lock anything. The main downside to this
solution is that
it is still possible for an edit lock to get hung. The good thing is that
only one
page would be affected, not the entire site.
Another solution is to find the reason why the script is leaving the lock,
and fix
that bug. In my experience, this will be impossible. CGI scripts do in
fact die
for no apparent reason sometimes, and it's very hard to trap/debug/etc. I
mean, it
is theoretically possible, but as a practical matter I find that something
is always
left hanging.
One of my own personal design philosophies is that everything should fail
gracefully.
That is, I accept that my own software sucks and will in fact break. This
is a matter
of humility before the gods of software. The best that I can hope for is
that when my
software does choke, it will do so gracefully. There will always be bugs
and things
that don't work right, but as long as they don't destroy the universe,
there's hope.
:-)
--Jimbo
--
http://www.nupedia.com/ *The Ever Expanding Free Encyclopedia *
[Wikipedia-l] To manage your subscription to this list, please go here: http://www.nupedia.com/mailman/listinfo/wikipedia-l
At 10:58 AM 8/25/01, you wrote:
Given your analysis, the idea of "per-file" edit locks sounds good to me. If that could be put together quickly, that would be great. But you don't sound quite sure that there's no significant risk if we were just to remove the edit locks altogether. I mean, what does a "collision" involve?
FWIW, if there *is* a push to move the Wikipedia across to MySQL, I believe that table write locking can be handled fairly easily by the database -- and that if a write request comes in while a table is write locked, it is simply queued to be performed once the table is available again. Of course, my programming experience with PHP and MySQL is not particularly extensive, and I've never really had to deal with a multi-user system, so maybe I'm just wrong.
Anyone?
As for removing the locks altogether -- well, any Discworld readers care to point out how often the "million to one chance of a collision" would occur?
Pete.
Peter Jones wrote:
As for removing the locks altogether -- well, any Discworld readers care to point out how often the "million to one chance of a collision" would occur?
Oooh, do tell, a horror story? I love those!
In this case, if there were no locks and the "million to one chance of a collision" occurred, the worst that can happen is that one article gets corrupted.
That's bad, of course, but the edit lock problem persists in being persistently annoying.
It might be a lot better if I just looked into a 'one lock per article' solution.
Jimmy Wales jwales@bomis.com writes: [BTW, your article was hard to read due to lines longer than 80 chars]
Here's my understanding of the edit lock problem...
I've written [[Wikipedia/Edit lock]] now. If the monastery metaphors are two cheesy, feel free to delete ... as always.
There are several possible solutions. My own personal solution is wild. I just wouldn't use a lock at all. You run the risk of collisions, but these are so rare *in my experience* as to be worth ignoring.
Hmm, I don't think I'd risk that. My understanding is that this could damage not only the current version/html cache, but also the revision history. I'm not even sure the software could reliably detect this condition (humans could of course).
Another solution is to have 'per-file' edit locks.
Sounds good.
CGI scripts do in fact die for no apparent reason sometimes, and it's very hard to trap/debug/etc.
It's perl, right? So you could hang a handler onto various hooks that removed the evil lock.
if (create_lock()) { $SIG{__DIE__} = $SIG{TERM} = ... = &release_lock; ... release_lock(); }
Perl itself could die, but that's probably less often.
Also, instead of creating a directory, why not create a file that holds the PID? This way stale locks can be removed with some certainity.
until (sysopen(F, $lockName, O_WRONLY|O_CREAT|O_EXCL)) { if ($! != EEXIST) { die("can't make $LockDir: $!\n") if $errorDie; return 0; } if ($n++ >= $tries){ print STDERR "failing lock for $name, $tries, $wait, $errorDie\n"; return 0; } if (open(F, "<$lockName")) { my $pid = <F>; close(F); chomp($pid); unless (kill(0, $pid)) { # the lock holder no longer exists, remove it and respin immediately unlink($lockName) or die("couldn't remove $lockName: $!"); next; } } sleep($wait); } print F "$$\n"; close(F) or die("couldn't write to $lockName: $!"); return 1;
wikipedia-l@lists.wikimedia.org