System operations like GUI updates and data imports can corrupt data if they are run while a different user is updating the database. The system enters single-update mode (SUM) when operations that can affect data elsewhere in the system are performed. When STEP enters SUM, only the connection that is in SUM can update the database.
Important: Systems running an Oracle database, use Single-Update Mode (SUM)—documented below. Since SUM can block a system for long periods of time and since SUM is difficult to achieve on systems with a large amount of data, a system can benefit from enabling LFSC. The option to run LFSC while using Oracle is outlined in the Lock-free Schema Change topic. By default, systems running a Cassandra database use 'Lock-free Schema Change' (LFSC) functionality.
A connection can only enter SUM if no other connection in the system is in SUM. If it is not possible for the system to enter SUM, or if a user tries to make changes or update when another connection is in SUM, a warning message displays as shown below.
Additionally, if you log on to the system while it is in SUM, a warning displays.
The warning displays information about which connection is currently running in SUM. While the user who is not in SUM cannot change data, they can still view data.
Note: To allow the importer to enter SUM, when importing a STEPXML file, on root 'STEP-ProductInformation' tag, set the 'SingleUpdateMode' XML attribute to 'Y' as defined in the SingleUpdateMode in STEPXML topic of the Data Exchange documentation. Without this setting, SUM operations are ignored during import.
Operations that Cause SUM
The following operations will cause the system to enter single-update mode (SUM).
-
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
SUM Examples
The following examples are not intended to describe all scenarios in which the Single-Update Mode (SUM) is triggered, but do illustrate some actions 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 dimension dependency, 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 record that 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, 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 recorded 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 SUM when changing attribute definitions, use the following procedures:
- 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 SUM then errors in data could occur.