Considerations when selecting a locking policy

When selecting a locking policy, consider the effects of the various locking policies.


Task group locking

Task group locking is the default locking policy. Task groups are the smallest unit of work in a workspace that can be committed to the production-ready data. Changes to managed assets within a workspace are always associated with the task and task group that made the last change to the managed assets, but the changes can be committed only to the production-ready data scoped to the task group. All changes within a task group are committed as a single transaction to the production-ready data.

When multiple task groups are involved, task group locking prevents potential inconsistencies where a managed asset is created or updated in one task group and therefore cannot be updated again in a different task group that is to be committed later.

However, the task group locking policy will not completely remove interdependencies such as those involving relationships between managed assets.

Consider the following events in one workspace:

Given these events, you could encounter the following scenarios:

The completion and approval of work might not result in content being activated immediately. It must wait until any dependent task group is completed. Alternatively, we can avoid dependency delays and schedule the task group work accordingly, either by activating task groups at a certain time or using the scheduled promotion feature.


Task locking

With task locking, the locking is at a more granular level than the commit level of a task group, so the same considerations apply to both task locking and task group locking.


Workspace locking

Workspace locking will allow task groups within the same workspace to modify a resource. Within the same workspace, the last task group to modify a managed asset becomes its owner and the managed asset will be committed to the production-ready data when the task group is committed.

In addition to the issues with task group locking, workspace locking has additional issues such as the following scenario:

When TG1 is completed, the commit will fail because productX will belong in TG2. The catalog associations created in TG1 will not succeed without productX when TG1 is committed to the production-ready data. To prevent this, TG1 and TG2 will need to be committed together when both are complete.


No locking

With no locking, any task or any workspace is allowed to update a resource. When working within one workspace under this locking policy, the last task group to modify a managed asset becomes its owner and the scenarios as described under workspace locking apply.

However, when the same managed asset is updated by multiple workspaces under this locking policy each workspace can store its own instance of the managed asset. Each workspace can have a copy of a managed asset and is free to commit this managed asset to the production-ready data at any time. Changes from one workspace might be overwritten when the same managed asset is touched in another workspace or could prevent a task group in another workspace data from being committed.

For example, a Workspace Content Contributor adds a new product under category X in one workspace and another Workspace Content Contributor deletes category X in a different workspace. If the data in the second workspace is committed to the production-ready data first, then the data in the first workspace cannot be committed.

Running with no locking risks the most problems and should be used only if you have intimate knowledge of the business processes that affect our production data. For example, if you only have a few Workspace Content Contributors who each own specific components of the content, we might make use of this model. Each Workspace Content Contributor owns a specific component, so the same Workspace Content Contributor would modify a managed asset even though it might occur in multiple workspaces. The Workspace Content Contributor must understand any conflicting changes. Typically, updating and creating content between workspaces would not cause potential conflicts for the commit except where the unique index is involved. An example is trying to update a product part number to a value introduced in another workspace or the production-ready data. Deleting managed assets, such as removing associations or moving products, risks causing conflicts.


Related concepts
Workspaces locking policies
Workspaces object locking


Related tasks
Changing workspaces locking policy


Related reference
Catalog component