Overview of a request for mastership

When a developer requests mastership of a branch, the branch's mastership is transferred to the developer's current replica. When a developer requests mastership of a branch type, mastership of the branch type, along with mastership of all the instances of the branch type that have default mastership, is transferred to the developer's current replica.

The procedure for requesting mastership is as follows:
  1. A developer makes a request for mastership.
  2. The developer's client host determines which replica masters the branch or branch type and sends a request for mastership to that replica. This request is made directly to the VOB server, not by sending an update packet.
  3. Authorization checking occurs at the sibling replica. The checks are different for a branch and a branch type.

    For a request for mastership of a branch, authorization checking determines the following:

    1. Whether the developer is allowed to request mastership.
    2. Whether requests for mastership of the branch are allowed at the replica level, the branch type level, and the branch level.
    3. Whether the replica masters the branch. If the replica does not master the branch, the mastership request fails.
      Note: If the sibling replica has transferred mastership of the branch to another replica, but the current replica has not received an update packet with that change, the information at the current replica is not up to date.
    4. Whether the branch, its branch type, or VOB is locked. If one or more of these objects are locked, the request fails (even if the developer is on the –nusers list).
    5. Whether there are any checkouts on the branch, except for unreserved, nonmastered checkouts.
    6. Whether the branch is associated with a stream. You cannot request mastership of a branch associated with a stream.

    For a request for mastership of a branch type, authorization checking determines the following:

    1. Whether the developer is allowed to request mastership.
    2. Whether requests for mastership of the branch type are allowed at the replica level and the branch type level. Also, whether requests are allowed for all of the branch type's instances that have default mastership. If requests are denied at the replica or branch type level, or for any instances that have default mastership, the request fails.
    3. Whether the replica masters the branch type. If the replica does not master the branch type, the mastership request fails.
      Note: If the sibling replica has transferred mastership of the branch type to another replica, but the current replica has not received an update packet with that change, the information at the current replica is not up to date.
    4. Whether any of the following objects are locked: the branch type, the VOB, or any of the branch type's instances that have default mastership. If one or more of these objects are locked, the request fails (even if the developer is on the –nusers list).
    5. Whether there are any checkouts (except for nonmastered checkouts) on any of the branch type's instances that have default mastership.
    6. Whether the branch type is associated with a stream. You cannot request mastership of a branch type associated with a stream.

    If the request passes the authorization checks, the process continues. (If the developer requests mastership of multiple branches or branch types, error messages are printed for the failures and processing continues.)

  4. The server process for the sibling replica assigns mastership of the branch or branch type to the developer's current replica.

    The event record for this operation includes the user name of the requesting developer as part of the comment.

    Note: At this point, the sibling replica is the only replica in the family that has information about the mastership change. At all other replicas in the family, including the developer's current replica, the current mastership information shows that the sibling replica masters the branch or branch type. The developer's current replica is updated only when the update packet that will be created in the next step is imported. The other replicas in the family are not updated until they are synchronized with either of the two replicas that has information about the change.
  5. The server at the sibling replica starts an export process to create and send an update packet containing the mastership change to the developer's current replica.

    This packet also contains other changes made since the last synchronization export.

  6. The mastership request operation completes its processing.

After the update packet is imported successfully at the developer's current replica, the branch or branch type is mastered by the current replica. Developers using that replica can create new versions on the branch or create new instances of the branch type.

Note: A request for mastership does not initiate a syncreplica –import command. If the replica's host uses a receipt handler (the recommended procedure), the import begins as soon as the packet arrives. Otherwise, the import occurs at the scheduled import time for the replica or when an administrator imports the packet manually.