[Wikipedia-l] Edit locks

[Larry Sanger]

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 at bomis.com>
To: <wikipedia-l at 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