in reply to Best way to handle locking of nodes being edited?

As a clarification, we are looking for a way to keep two editors from accidentally editing the same node at the same time. We realize that a node lock would do this, but then there are the issues of lost locks, and so forth.

I think that a simple solution is a good starting point, and if we find that a more "complex" solution is needed, it can always be changed. "Simple" in my book is that an editor selects to edit a node, and if no one else is editing it, is given the editor screen. Otherwise the editor is given the name of the current editor. A lock expires after 20 or 30 minutes.

  • Comment on Re: Best way to handle locking of nodes being edited?

Replies are listed 'Best First'.
Re: Re: Best way to handle locking of nodes being edited?
by dws (Chancellor) on Feb 23, 2001 at 00:47 UTC
    If you want to prevent two editors from editing the same node simultaneously, then you'll need some form of "pessimistic" locking scheme. Obtain some form of lock up front, preventing anyone else from even attempting an edit.

    Alternatively, if you judge that the chance of edit collisions is slim, you can adopt a less expensive "optimistic" scheme were the first edit saved wins. A hidden timestamp in the edit form is sufficient for this. If the timestamp doesn't match the page/node timestamp when a save is attempted, the save loses (becomes a merge attempt).

    A data point:

    I use an optimistic scheme in a Wiki clone. It gets far less traffic than Perlmonks, but it's often the case that there's a "working set" of a dozen active pages during the course of a day, and edit collisions are rare. Given how quickly people jump on new nodes here, that might not be the case here.

[reply]
Re (tilly) 2: Best way to handle locking of nodes being edited?
by tilly (Archbishop) on Feb 23, 2001 at 00:48 UTC
    As a further clarification, I am still unconvinced that there is a problem with multiple editors editing at once. If a node requires editing, it is probably obvious what the edit is. Should 2 people race to do the same work, oh well.

    At most have a message saying that "so and so started editing this time X ago" and let the editor decide whether they want to proceed.

[reply]

      I agree. But since vroom asked, I assumed that he had a reason (such as wanting to implement automatic "undo").

      If you add to the above scheme a simple atomic test at final commit time to see whether the node has be changed since the editting began (as discussed already), then the editor can be warned that they are about to overwrite someone else's work. At that point, they can open another window and view the other work and decide whether to commit their own changes or not (or to merge some of the other editor's changes, etc.).

              - tye (but my friends call me "Tye")
[reply]
      Would that message clear when the "other" editor stubmit's the edit? Also, 'x' becomes a variable timeout, right?
[reply]

        In an ideal world, the list of people editing a node (in the case of editors) or replying to a node (for everyone) would get cleared out after a pretty long time (like an hour), if the edit/reply is ever committed, or if the editor/replier hits "Cancel" (a new button whose sole purpose is to remove you from the list of editors/repliers for a node, just out of courtesy).

        But a first stab at this could skip the last item in the list to save development time.

                - tye (but my friends call me "Tye")
[reply]

In Section Perl Monks Discussion