Lock Free Schema Change

Certain system operations (i.e., GUI updates, data import) can corrupt data by deleting unintended data and creating inconsistencies if they are run at the same time a different user is updating the database. Because of this, systems running a Cassandra database use Lock Free Schema Change (LFSC) functionality. Systems running an Oracle database, by default, use Single-Update Mode (SUM)—documented in the Single-Update Mode topic here. However, as described in the 'Enabling the LFSC Functionality' section at the end of this topic, there is an option to run LFSC if using Oracle.

LFSC works by dividing the schema change up into several parts. This is an example of how it works and what happens for an attribute change:

  1. Make a new attribute in the background with the wanted definition.

  2. Copy all present (not historic) values from the old attribute to the new attribute.

  3. Modify the new (still unused copy) to suit the new definition.

  4. Swap the IDs of the new and the old attributes.

  5. Delete the old present values NOT including the attribute or the historic values.

Engaging the LFSC Functionality

The following operations use LFSC functionality: 

  • Deleting a workspace. For more information, refer to the Maintaining Workspaces topic in the System Setup documentation here.

  • Adding or deleting Dimension dependencies

  • Merging Attributes (with the exception of Bulk Updates where values are copied to new attributes)

  • Changing Attributes to or from being externally maintained

  • Changing Attributes to use or not to use LOV

  • Changing Attributes to or from being free text searchable

  • Changing Attributes to or from being multi valued

  • Activating or deactivating unique keys

  • Changing reference types to or from being externally maintained

  • Changing reference types to or from being multi valued

  • Changing Product to Classification Link Types to or from being externally maintained

  • Changing or moving Product to Classification Link Types (for example, when you move one type to another type)

  • Changing Product to Classification Link Types to or from being multi valued

  • Merging LOVs (unless neither LOV is in use by an attribute)

  • Removing Object Types

  • Changing the Revisability setting of an entity object type

  • Changing the validity of a Data Container Type for an Entity Type

  • Changing Data Container Type parameter Allow multiple values to 'No'

Note: All changes previously requiring SUM have been implemented with LFSC with one exception. It is not possible with LFSC to change the Owns Product Links setting on a classification object type.

Using / Switching to LFSC: Considerations

In addition to the information above, there are multiple things that must be considered before using LFSC by default (Cassandra) or switching to and using LFSC (Oracle):

  • LFSC runs in a background process (BGP), and it is VITAL that this process is allowed to finish. If it fails, it must be resumed or deleted in order to get cleaned up again.

    • You can monitor the 'Schema Change' background process.

  • If you are unable to do anything else in the workbench or Web UI after manually initiating an LFSC (i.e., the UI appears unresponsive), and the Reading / Writing Data pop-up displays, close out the session you started the process in and create a new session.

  • Changes made via LFSC do not retain the revision history.

  • It can take longer to complete an LFSC operation than a SUM update.

Customers with huge amounts of data can benefit from LFSC, because on those systems with LFSC enabled, it is often very hard to get into SUM. When in SUM, it can block the system for long periods of time.

It is important to consider all implications when deciding to use LFSC.

Enabling the LFSC Functionality

Oracle database systems running In-Memory can opt to use LFSC over SUM. No action is needed for Cassandra systems.

For on-premise or SaaS systems, create an issue in the Stibo Systems customer support portal for assistance.