Certain system operations (i.e., GUI updates, data import) can corrupt data if they are run at the same time that a different user is updating the database.
Important: 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 below. There is an option to run LFSC if using Oracle, and that option is outlined in the Lock-free Schema Change topic. 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.
The system enters single-update mode when operations that can affect data elsewhere in the system are performed. When STEP enters single-update mode, only the connection that is in single-update mode can update the database.
A connection can only enter single-update mode if no other connection in the system is in single-update mode. If it is not possible for the system to enter single-update mode, or if a user tries to make changes or update when another connection is in single-update mode, a warning message displays.
Additionally, if you log on to the system while it is in single-update mode, a warning displays.
The warning displays information about which connection is currently running in single-update mode. While the user not in single-update mode cannot change data, they can still view data.
Note: The importer will only allow entry into single-update mode if attribute 'SingleUpdateMode' on root tag 'STEP-ProductInformation' is 'Y'. Otherwise single-update mode operations would be ignored during import.
Operations that Cause Single-Update Mode
The following operations will cause the system to enter single-update mode.
-
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
-
Changing the Owns Product Links setting on classification object type as defined in the Owns Product Links on Alternate Classifications Object Type topic
-
Changing the Reference Target Lock Policy on object types, as defined in the Reference Target Lock Policy on Object Types topic
-
Using the Attribute Value Migration functionality for attribute values that were created on pre-8.1 STEP systems, as defined in the Attribute Value Migration topic
Single-Update Mode Examples
The following examples are not intended to describe all scenarios in which the Single-Update Mode (SUM) is triggered, but are listed to illustrate some possible issues that SUM may introduce.
Example 1: Add / Remove a Dimension Dependency
If a user adds or removes a dimension dependency at the same time someone else is manipulating data that uses that is dimension dependency, then there is a risk of introducing inconsistent data in the database for the particular data that is being manipulated.
Note: Only the concurrently manipulated data is at risk.
For example, adding a dimension dependency to an attribute while data for this attribute is simultaneously being imported could result in inconsistent data. One way this might occur is if the importer caches the attribute's dimension dependency but does not notice the new dimension dependency has been applied until a number of seconds have elapsed. In that interim period, the values written for this attribute will have the wrong dimension dependencies.
Example 2: Merge Attributes
If one user is manipulating values on an attribute while a different user is merging that attribute, then there is a risk that inconsistent data may be introduced. This applies to all attributes participating in the merge.
Note: Only the concurrently manipulated values are at risk.
One example of how this might occur is if one user is importing values into the primary attribute at the same time another user is merging a different attribute into the same primary attribute. The merge operation might find a value of the secondary attribute to merge into the primary attribute, and at the same time, the other operation might create a new value for the same product for the primary attribute. These two values might be visible in same workspaces / contexts and be in conflict.
Another potential scenario where this could occur is when one user is importing values into an attribute that is about to be deleted by another user's operation. The import succeeds because the secondary attribute was still present as the second user's process was initiated. However, once the merge is complete, the imported values are deleted with the attribute, thus the merge operation is unable to merge the values because the system did not detect the values in time.
Example 3: Changing the Property of an Attribute
This example covers the following four operations:
- Change the 'Externally Maintained' flag of an attribute (i.e., store the historic values of an attribute or not)
- Change an attribute to or from using LOV validation
- Change an attribute to or from being a BLOB (Binary Large OBject). That is, making an attribute free text searchable or by changing its value length past the 100 bytes boundary
- Change an attribute to or from being multi-valued
Changing one of these properties at the same time as another user is manipulating values of the attribute might result in inconsistent data.
Note: Only the concurrent manipulated values are at risk.
For example, changing one of these settings of an attribute while at the same time importing data for this attribute could lead to inconsistent data being imported for the attribute. The importer might have cached the original property of the attribute and not noticed the change until after a few seconds. In these few seconds, values written for this attribute will have an incorrect state, and these values will not be remedied by the batch operation since it has already moved past this point in the database table.
Guidance for Preventing SUM Activation
To avoid entering single-update mode when changing attribute definitions, the following procedure can be used:
- Create a new attribute (Attribute B) with the same desired attribute definition (including the changes from the origin attribute, Attribute A).
- Use Bulk Update in the STEP Workbench to copy all attribute values from Attribute A to Attribute B. For more information on using bulk update functionality, refer to the Bulk Updates topic within the Getting Started documentation.
- Switch the IDs of Attribute A and Attribute B. To do this, navigate to either attribute on the System Setup tab of the workbench. Right-click on the attribute and select 'Switch Attribute IDs'. In the resulting dialog, select the attribute that the selected attribute should swap IDs with.
If a user attempts the above actions without entering into single-update mode then errors in data could occur.