Workspaces locking policies
Locking policies in workspaces allow you to control how changes are made and who is able to make the changes. A locking policy determines if managed assets are locked to a workspace, task group, or task, or if they are not locked at all. The locking policy applies to the entire WebSphere Commerce site and is not configurable by store.
In the Catalogs tool, for example, the locking policies remain unchanged but the locking level is applied at a high level logical business object with finer grain locks on subobjects. For example, a catalog entry is a logical object with subobjects defined for offer price, navigational relationships, and merchandising associations. An update to properties such as the name, description, or attributes of a catalog entry in the workspace applies a lock on the logical catalog entry. This catalog entry becomes read-only to other users in other workspaces, task groups, or tasks based on the locking policy. However, the lock on the catalog entry would not prevent users in another workspace task to update a subobject such as an offer price. Updates made to an offer price acquire individual locks specific to the change, but would not lock other subobjects, or the logical object itself. The Catalogs tool indicates when a logical object has been changed within a workspace in the Object Properties view. Further, within the Catalogs tool, the workspace lock on objects applies to the Approved data area. A user is prevented from changing object data in the Approved area if the corresponding object was modified in a workspace task. However, an emergency fix workspace can still bypass the locks.
There are four possible locking policies initially available in WebSphere Commerce:
- Workspace locking
- With this locking policy enabled, a managed asset is locked to the workspace when the first
change is made to the asset within the workspace. Workspace Content Contributors assigned any task
in the workspace can make changes to the locked managed asset.
Users working in any task group and tasks in the workspace where the managed asset is locked can make changes. Users working in other workspaces cannot change the locked managed asset.
- Task group locking
- With this locking policy enabled, a managed asset is locked to the task group in which a
Workspace Content Contributor first changes the asset. Only Workspace Content Contributors assigned
tasks in the same task group can make changes to the locked managed asset.
Task group locking is the default locking policy for workspaces.
Users working in other task groups cannot change the locked managed assets. Only users assigned tasks within the task group where the managed asset is locked can change the managed asset.
- Task locking
- With this locking policy enabled, a managed asset is locked to the task in which a Workspace
Content Contributor first changes the asset. Only Workspace Content Contributors assigned to the
same task can make changes to the locked managed asset.
Only users assigned to the same task where the managed asset is locked can change the managed asset.
- No locking
- With this locking policy enabled, there are no restrictions on changing managed assets in a workspace. Any user in any workspace can change managed assets. Users could make changes to the same managed assets in different workspaces which can cause problems when those workspaces are committed.
Once locked, managed assets remain locked until a workspace, task group, or task is completed or canceled, depending on the locking policy. For example, if you cancel a task group when using the task locking policy, all managed assets locked by all tasks in the canceled task group will be unlocked. When you cancel a task group, all changes made through tasks in the task group are lost.
Before deciding on the locking policy to use on your authoring server, review the Considerations when selecting a locking policy topic carefully to understand the implications of each locking policy.