In order for you to enable requests for mastership in one or more replicas, the following conditions must apply:
A request for mastership makes remote procedure calls (RPCs) directly to remote servers and fails if the hosts are not connected. If a site has a firewall, developers at that site cannot request mastership from replicas at other sites, and developers at other sites cannot request mastership of any branches mastered by a replica at a site with a firewall.
If a replica does not master its own replica object, you cannot enable or disable mastership requests at the replica level. For information about reassigning mastership of the replica object, see Transferring Mastership of a Replica Object.
For mastership requests to work efficiently, the following conditions must apply:
If two or more developers at different sites compete for mastership of objects, mastership will always be in flux. In this situation, the project leaders and administrators must determine whether the branch sharing strategy needs to be changed. Using requests for mastership is not a substitute for using good branching and merging practices.
Each replica needs current information about object mastership. If a replica is not up to date, requests for mastership from that replica cannot determine which replica masters the requested object. Also, if replicas exchange packets infrequently, a mastership request may cause the generation of a large update packet, which will take longer to generate and import.
You can schedule scripts to import packets regularly. However, to import a packet as soon as it arrives at the replica host, you must use a receipt handler. For more information, see Defining Receipt Handlers on UNIX and Defining Receipt Handlers on Windows.