Durability and Consistency Data Types
This section defines the data types used to support durability and consistency policies.
kv_ack_policy_enum
typedef enum {
    KV_ACK_ALL = 1,
    KV_ACK_NONE = 2,
    KV_ACK_MAJORITY = 3
} kv_ack_policy_enum;A replicated environment makes it possible to increase an application's transaction commit guarantees by committing changes to its replicas on the network. This enumeration defines the policy for how such network commits are handled.
Ack policies are set as a part of defining a durability guarantee. You create a durability guarantee using kv_create_durability().
Possible ack policies are:
- 
                           KV_ACK_ALLAll replicas must acknowledge that they have committed the transaction. 
- 
                           KV_ACK_NONENo transaction commit acknowledgments are required and the master will never wait for replica acknowledgments. 
- 
                           KV_ACK_MAJORITYA simple majority of replicas must acknowledge that they have committed the transaction. 
kv_consistency_enum
typedef enum {
    KV_CONSISTENCY_ABSOLUTE = 0,
    KV_CONSISTENCY_NONE,
    KV_CONSISTENCY_TIME,
    KV_CONSISTENCY_VERSION,
    KV_CONSISTENCY_NONE_NO_MASTER
} kv_consistency_enum; Enumeration that is used to define the consistency guarantee used for read operations. Values are:
- 
                           KV_CONSISTENCY_ABSOLUTEA consistency policy that requires a read transaction be serviced on the Master so that consistency is absolute. 
- 
                           KV_CONSISTENCY_NONEA consistency policy that allows a read transaction performed at a Replica to proceed regardless of the state of the Replica relative to the Master. 
- 
                           KV_CONSISTENCY_TIMEA consistency policy which describes the amount of time the Replica is allowed to lag the Master. This policy cannot be specified using kv_create_simple_consistency(). Instead, use kv_create_time_consistency(). 
- 
                           KV_CONSISTENCY_VERSIONA consistency policy which ensures that the environment on a Replica node is at least as current as that used by the Value provided to kv_get_version(), or by the result set provided to kv_result_get_version() or kv_result_get_previous_version(). This policy cannot be specified using kv_create_simple_consistency(). Instead, usekv_create_version_consistency(). 
- 
                           KV_CONSISTENCY_NONE_NO_MASTERA consistency policy that requires a read operation be serviced on a replica; never the Master. When this consistency policy is used, the read operation will not be performed if the only node available is the Master. For read-heavy applications (ex. analytics), it may be desirable to reduce the load on the master by restricting the read requests to only the replicas in the store. Use of the secondary zones feature is preferred over this consistency policy as the mechanism for achieving this sort of read isolation. But for cases where the use of secondary zones is either impractical or not desired, this consistency policy can be used to achieve a similar effect; without employing the additional resources that secondary zones may require. 
kv_sync_policy_enum
typedef enum {
    KV_SYNC_NONE = 1,
    KV_SYNC_FLUSH = 2,
    KV_SYNC_WRITE_NO_SYNC = 3
} kv_sync_policy_enum;Defines the synchronization policy to be used when committing a transaction. High levels of synchronization offer a greater guarantee that the transaction is persistent to disk, but trade that off for lower performance.
Sync policies are set as a part of defining a durability guarantee. You create a durability guarantee using kv_create_durability().
Possible sync policies are:
- 
                           KV_SYNC_NONEDo not write or synchronously flush the log on transaction commit. 
- 
                           KV_SYNC_FLUSHWrite and synchronously flush the log on transaction commit. 
- 
                           KV_SYNC_WRITE_NO_SYNCWrite but do not synchronously flush the log on transaction commit.