Considerations when selecting a locking policy

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:

• Under one task group (TG1), a product (productX) and two SKUs (sku1, sku2) are added to the master catalog under a category (categoryX).
• Under a second task group (TG2), productX is visible and is used and added into a sales catalog under a category (categorySCX).
• Under a third task group (TG3), productX is visible and is used to create an upsell association to product (productY).
• Under a fourth task group (TG4), productX is used in a promotion where its upsell association is used to reference content in an eSpot.

Given these events, you could encounter the following scenarios:

• If TG2, TG3, or TG4 are approved and completed before TG1 is complete, they will experience a commit failure because they are dependent on productX which has yet to be approved. As such, it does not exist in the production-ready data and a database exception will occur.

  This is not necessarily a problem. These task groups will remain in a state where the work is complete, but cannot yet be committed. When TG1 is completed and approved, the system will attempt to commit all available task groups under a single transaction.

• If TG4 is completed and approved first, there are no errors except that the content that the marketing promotion refers to does not exist. The Workspace Content Contributor or Task Group Approver of TG4 which previewed and saw the content correctly will not see the content after TG4 is committed.

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, you 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:

• A product (productX) is created in a task group (TG1) and assigned to the catalog, creating catalog associations.
• productX's description is subsequently updated in a second task group (TG2).

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 your production data. For example, if you only have a few Workspace Content Contributors who each own specific components of the content, you 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.