If there is a partition, e.g., the runtime running the protocol belongs to an active cluster that is a proper subset of the total multi-cluster, step 302 instead branches to step 306, which operates when an activation needs to be created in response to an application request. Note that if an activation already is instantiated (activated) in the active cluster, the runtime simply uses that activation and returns information to the application so the application will use the existing activation instance.

As set forth above, if a component (whether specifically identified or by being of a certain class/type) is allowed to be created (possibly as a duplicate) in the high availability mode, step 308 branches to step 314 where the activation is created, but with a DOUBTFUL status to indicate it is a possible duplicate.

Conversely, if an activation is only allowed to be created in the high consistency mode but a partition exists, then step 308 branches to step 310, which evaluates whether the cluster is part of the quorum. If not, the activation request is denied at step 312. Note that in the alternative, most restrictive high consistency scenario, step 310 may be bypassed, that is, the request is denied as represented by step 312 regardless as to whether a cluster is part of the quorum.