Concurrency Control

About Concurrency Control

"Concurrency" is a term associated with databases. It is a feature that allows multiple users to interact and affect data "concurrently". This feature is unique to databases and alternative "flat" data storage options such as Spreadsheets do not offer this ability.

"Concurrency Control" is the term used to describe mechanisms put in place to ensure data integrity within multiuser environments. Example problem:

  1. User A reads data for ticket #321
  2. User B reads data for ticket #321
  3. User A updates data for ticket #321
  4. User B updates data for ticket #321
The problem: User B's changes conflict with User A's and unless handled correctly User A's changes will be lost without anyone knowing.

In a multiuser application that is backed by a database such as Project on Demand there are two ways of handling concurrency control to ensure all users see the same data and any conflicts between user driven changes to the data are handled correctly to avoid inadvertent overwriting of data:

  • Optimistic Concurrency Control - When attempting to save changes to the database, check whether the data stored in the database matches the original retrieved, if it doesn't then another user has made changes to the data and the operation should be handled differently.
  • Pessimistic Concurrency Control - Lock the data so it may only be edited by 1 user at a time, effectively removing the possibility for any conflicts between user changes to arise.

Both of the above concurrency control methods are utilised within the Project on Demand application. Pessimistic concurrency control "locking" has been implemented in a small number of areas where simultaneous users effecting data would be problematic, the remaining parts of the application implement optimistic concurrency control.

The exact mechanisms implemented within Project on Demand are detailed as follows:

Optimistic Concurrency Control within Project on Demand

Optimistic concurrency control has been implemented everywhere pessimistic concurrency control has not.

Given the example above, in Project on Demand when User B attempts to save his change they will be presented with a confirmation window informing them of the conflict and offering two options in how to proceed:

  • Option #1 - Cancel any changes the current user has made and retrieve the data stored in the database. In our example it would retrieve the ticket data including the change User A had already made.
  • Option #2 - Ignore any conflict and overwrite the stored data with the data from the current user. In our example it would overwrite User A's change.

Note about Documents: Documents have optimistic concurrency control implemented on them as a whole, however "child" items contained within Documents follow different rules depending on what they are:

Pessimistic Concurrency Control within Project on Demand

Pessimistic concurrency control has been implemented in the following areas:

These areas contain data that is likely to be viewed and possibly edited by multiple people simultaneously, to prevent excessive conflicts being detected and having to be resolved like in optimistic concurrency control, these areas are "locked" to only one User at a time.

The first user to enter any of the above areas in "Edit Mode" will initiate the locking mechanism.

The locking mechanism has a timer of 5 minutes and the application will refresh the lock periodically if left open. Navigating out of the above areas will remove the lock, however if the application or browser is closed without the user navigating away, the area will remained locked for the remaining time left.

Additional users to enter any of the above areas after a lock has been applied will only be allowed in "Read-Only Mode" and will be presented with a message informing them of the lock and by whom it was applied. The Check Again button can be used to recheck the lock status and attempt to apply a new lock for the current user if a lock by the previous user no longer exists.

A 30 minute idle prevention timer is implemented - after 30 minutes of a lock being in place the user will be presented with a confirmation window asking them if they wish to continue, if there is no response after 5 minutes or No is clicked the user will be taken to the Dashboard and any unsaved changes will be lost. This feature is implemented to prevent locks being in place for extended periods of time because another user accidentally left their application open with a lock still in place.