If true, the replication master will automatically re-initialize outdated clients (defaults to true).

If true, the replication master will send groups of records to the clients in a single network transfer

If true, the client will delay synchronizing to a newly declared master (defaults to false). Clients configured in this way will remain unsynchronized until the application calls RepSync()()().

If true, Replication Manager automatically runs elections to choose a new master when the old master appears to have become disconnected (defaults to true).

If true, Berkeley DB method calls that would normally block while clients are in recovery will return errors immediately (defaults to false).

Specify how master and client sites will handle acknowledgment of replication messages which are necessary for "permanent" records. The current implementation requires all sites in a replication group configure the same acknowledgement policy.

A list of site configurations.

If true, the Replication Manager will observe the strict "majority" rule in managing elections, even in a group with only 2 sites. This means the client in a 2-site group will be unable to take over as master if the original master fails or becomes disconnected. (See the Elections section in the Berkeley DB Reference Guide for more information.) Both sites in the replication group should have the same value for this parameter.

The delegate used to transmit data using the replication application's communication infrastructure.

If true, master leases will be used for this site (defaults to false).