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. 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, as defined in the Maintaining Workspaces topic

• Adding or deleting dimension dependencies, as defined in the Dimension Dependent Attributes topic

• Changing externally maintained on attributes, as defined in the Externally Maintained Attributes topic

• Changing attributes to use or not to use LOV, as defined in the Editing Validation Rules topic

• Changing attributes to or from being Full Text Indexable, as defined in the Advanced Search Functionality topic in the Getting Started documentation

• Changing attributes to or from being multi valued, as defined in the Validation Rules topic

• Activating or deactivating unique keys, as defined in the Activating and Deactivating Keys topic

• Changing reference types to or from being externally maintained, as defined in the Maintaining a Reference Type topic

• Changing reference types to or from being multi valued, as defined in the Maintaining a Reference Type topic

• Changing product to classification link types to or from being externally maintained, as defined in the Maintaining a Product to Classification Link Type topic

• Changing or moving product to classification link types (for example, when you move one type to another type), as defined in the Maintaining a Product to Classification Link Type topic

• Changing product to classification link types to or from being multi valued, as defined in the Maintaining a Product to Classification Link Type topic

• Merging LOVs (unless neither LOV is in use by an attribute), as defined in the Merging LOVs topic

• Removing object types, as defined in the Deleting an Object Type topic

• Unlinking object types, as defined in the Unlinking Object Types topic

• Changing the revisability setting of an entity object type, as defined in the Revisability on Entity Object Type topic

• Changing the validity of a data container type for an entity type, as defined in the Setting Up Data Container Types in Workbench topic

• Changing data container types to or from being multi valued, as defined in the Setting Up Data Container Types in Workbench topic

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 Service Portal for assistance.