DCM protects objects by enforcing a policy that any specific object is only modifiable in one database in a DCM cluster at any point in time. In all other databases, the object cannot be modified unless you are in ccm_admin role. The only exception to this is that an object can be changed to a later state.
The controlling database for an object is determined by either the modifiable_in attribute or its created_in attribute. If the modifiable_in attribute exists, then the controlling database for the object is explicitly defined. The attribute value specifies the DCM database ID of the controlling database. If the modifiable_in attribute does not exist, then the controlling database is determined by the value of the created_in attribute.
The control of an object can be handed over from the current controlling database to some other database by changing the modifiable_in attribute value. Change the value from the current DCM database ID to the ID of the new controlling database. This operation marks the object as pending handover of control. It protects the object against update until acknowledgment has been received that the control has been successfully passed to another database. This acknowledgment is achieved by examining the object when received from another database. Handover of control is normally only provided for change requests, tasks, release definitions, processes, process rules, and folder templates. However, its use is not limited to any specific type of object.
DCM protects objects in a number of ways:
By default, when a DCM database definition is created, the Handover allowed setting is FALSE and you cannot hand over control to that database. If you want to hand over control of an object to another database, change this setting to TRUE.