Passive Synchronization

While invokes to entities in a high-availability deployment are typically replicated to be run on the active and the passive instances of the entity, across the stripe, that is only to maintain a consistent state. When a new passive comes online, it needs to catch up to this state, within the passive entity instances which will be living on it. This activity is called passive synchronization.

Passive synchronization takes place as 2 distinct phases:

• Entity instances are instantiated on the passive and each issued a createNew(), in the order they were initially created on the active. This is done so that all entity creation can depend on a consistent order across the stripe: if Entity B depends on shared resources established by Entity A, this creation order is maintained across all servers in the stripe.

• Entity data is synchronized from the active to the new passive. Note that this is done per concurrency key within each entity.

It is worth noting that this happens without directly blocking the flow of existing invokes entering the running active (although it is possible that a heavy-weight synchronization operation, on one key, could temporarily block other invokes from running there).

The first phase happens immediately after the new server determines its passive state. The active sends the list of entities to instantiate. Each is instantiated and receives a createNew call before the next phase begins. Note that, if one of these entities is deleted, before its data is synchronized (since that happens later), it will receive the replicated destroy call, never having its data synchronized.

Additionally, any newly-created entities will have their creation replicated to this new passive, even though the other entities may not be fully synchronized. However, this first phase ensures that the creation order of new entities will still be the same on all servers in the stripe.

The second phase runs concurrently with normal invoke replication. Each concurrency key of each entity is synchronized to the new passive. Once a key is synchronized, invokes to that key can be replicated. Note that this means that it is possible to see a partially-synchronized entity receiving replicated invokes on one key while still synchronizing another. For this reason, the entity implementation is allowed to direct the order in which its keys are synchronized (via ConcurrencyStrategy.getKeysForSynchronization() - the synchronization proceeds in the order dictated by this set’s iterator).