With respect to cluster membership, if a server S0 in cluster C is trying to create an activation A for component V, S0 first inserts an entry into its component directory of the form V=><A, REQUESTED_OWNERSHIP>, and then sends an ACTIVATION_REQUEST message to every cluster in its active multi-cluster. If, in the meanwhile, new servers are added to or deleted from cluster C, the range of VirtualComponentId hashes that S0 is responsible for may change. As a consequence, a subset of the data in S0's component directory partition may need to move to another server, S1. The change in the range of VirtualComponentId hashes that S0 is responsible for may occur while S0 is running the activation creation protocol.

A component directory entry for a component V is allowed to move from server S0 to server S1 even when S0 is running the activation creation protocol for component V. When the activation creation protocol is in progress, component directory entries are of the form V=><A, REQUESTED_OWNERSHIP>, or V=><A, RACE_LOSER>. When all the clusters respond with ACTIVATION_RESPONSE messages, S0 does not find a component directory entry corresponding to component V (because component directory entries may migrate). At this point, S0 recognizes that the component directory entry has moved to another server, and stops running the activation creation protocol. When the server to which the component directory entries have been migrated, S1, receives a component directory entry of the form V=><A, REQUESTED_OWNERSHIP>, or V=><A, RACE_LOSER>, it will run the activation creation protocol anew. In order to run the activation creation protocol, the ActivationState of the component directory entry corresponding to the activation needs to be in state REQUESTED_OWNERSHIP.