Oscailt Content Locking

In order to prevent simultaneous editing of content leading to lost content, oscailt implements a simple locking system. This system is used to prevent concurrent updates of stories, comments and objects.

Here is how locking works.

When an editor clicks 'edit' on a story (or comment or object) the editor gets a lock on the story. When the editor publishes the story they relinquish the lock.

If the editor is idle for 30 minutes (or whatever you set the time out to on the editconfiguration.php page) without saving and without previewing they lose the lock. Every time they click on 'preview' the timer is set back to zero and they get the lock for another 30 minutes or until they publish.

For this to work properly all that you have to do is to make sure that every time that you click "edit" you carry on and click publish - even if you change nothing. Otherwise the story will still be locked for the duration of the edit lock time out.

If somebody clicks on a page to edit a story (or comment or object) they get a lock. If the editor decides that they don't want to change anything and continues browsing the site without publishing, then everybody else is locked out of that story until the time is up.

You can make sure this doesn't happen by always publishing when you click edit even when you change nothing.

If you find a story is locked and suspect that somebody has wondered off without publishing it, you can email them to tell them to edit the story again and to click publish at the end - thereby releasing the lock and allowing somebody else to edit it.

When considering what duration of lock to use the following considerations apply:

• If the lock is set to too short a time span, then we will find situations where an editor starts editing an article, spends a good bit of time on it before clicking 'preview' or 'publish' and finds that their lock has expired and that somebody else has locked the story in the intervening period - locking them out of the story even though they have done lots of work on it.

• If the lock is set to too long a time span, then when people wander off without saving a story they were editing, other editors will be locked out for considerable lengths of time.

• There is also the potential problem of an editor keeping a story locked for a long period of time, for example by continuously clicking on preview without saving. Clicking on preview resets the time-out counter to zero since an editor may often edit a feature at length in several iterations. We can disable this be setting the system configuration variable forbid_consecutive_locks_without_save. If we set this variable then an editor will lose her lock after the lock times out regardless of whether she hits preview again.

Unfortunately, the problem of managing concurrent updates on the web to content is a difficult one and there is no purely technical solution - since the computer can't tell if you've given up editing the story and wandered off or haven't clicked any buttons since you've been too busy typing in the great novel of the 21st century. Instead solutions must have some element of human procedure about them.

-- ChekovFeeney - 08 Feb 2006