Edit Locks

Owned by Neill Magill
Oct 25, 2022
2 min read

The Problem

A problem with an enterprise-level system is you can have multiple users trying to edit the same question at the same time. Problems can occur in the following scenario:

  1. User 1 starts editing Question 'A'
  2. User 2 starts editing Question 'A'
  3. User 1 changes lead-in to "What is the capital of the United Kingdom"
  4. User 1 hits 'Save' button
  5. Question 'A' lead-in is now "What is the capital of the United Kingdom"
  6. User 2 meanwhile has changed the lead-in to "What is the capital of the Britain"
  7. User 2 hits 'Save' button
  8. Question 'A' lead-in is now "What is the capital of the Britain"
  9. User 1 decides he wants to change something else in Question 'A' and double-clicks to edit
  10. User 1 discovers the lead-in is "What is the capital of the Britain"

The Solution

Table: questions

To avoid this problem Rogo creates an edit 'lock' when the first user starts editing a question. When User 1 first starts to edit the question the field checkout_authorID is set to User 1's user ID and checkout_time is set to the current time. When User 2 starts editing the same question, the system will recognise that checkout_authorID is not NULL and will inform User 2 that User 1 has the question open for editing. This is how Microsoft Office works if multiple users try editing a document on a local network. Locks are released by turning both fields to NULL. This happens on both clicking 'Save' and 'Cancel'. The checkout_time field is used in situations where User 1 has just hit the back button in their browser and the question is still remains locked in the database. In this case the time/date stamp is looked at; if it is older than 60 minutes then Rogo will automatically override the lock and reassign it to User 2.