Notification mode architecture

A separate Sync Pipe is required for each client application that should receive a notification.

The Sync sources must consist of one or more instances of the following directory or proxy servers with PingDataSync:

You should not configure PingDataSync to interact with backend source servers through a load balancer. You can use PingDirectoryProxy for this configuration instead, assuming you are using PingDirectory servers as your backends.

For sync source failovers, configure replication between the PingDirectory servers to ensure data consistency between the servers. A PingDirectoryProxy server can also front the backend PingDirectory server set to redirect traffic if connection to the primary server fails. A PingDirectoryProxy server must be used for synchronizing changes in an entry-balancing environment. Once the primary PingDirectory server is online, it assumes control with no information loss because its state information is kept across the backend PingDirectory servers.

For sync destination failovers, connection retry logic must be implemented in the server extension, which will use the Sync Pipe’s advanced property settings to retry failed operations. There is a difference between a connection retry and an operation retry. An extension should not retry operations because PingDataSync does this automatically. However, the server extension is responsible for re-establishing connections to a destination that has gone down, or failing over to an alternate server. The server extension can also be designed to trigger its own error-handling code during a failed operation.

For PingDataSync failovers, the secondary PingDataSync servers will be at or slightly behind the state where the primary server initiated a failover. Both primary and secondary PingDataSyncs track the last failed acknowledgement, so once the primary server fails over to a secondary server, the secondary server will not miss a change.

Multi-threaded Sync Pipes allow PingDataSync to process multiple notifications in parallel in the same manner as synchronizing changes in standard mode, which increases throughput and offsets network latency. A single change-detection thread pulls in batches of change log entries and queues them internally. To guarantee consistency, PingDataSync’s internal locking mechanisms ensure the following properties:

The number of concurrent threads is configurable on the Sync Pipe using the num-worker-threads property. In general, single-threading should be avoided.