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