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_ALL

    All replicas must acknowledge that they have committed the transaction.

  • KV_ACK_NONE

    No transaction commit acknowledgments are required and the master will never wait for replica acknowledgments.

  • KV_ACK_MAJORITY

    A 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_ABSOLUTE

    A consistency policy that requires a read transaction be serviced on the Master so that consistency is absolute.

  • KV_CONSISTENCY_NONE

    A 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_TIME

    A 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_VERSION

    A 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_MASTER

    A 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_NONE

    Do not write or synchronously flush the log on transaction commit.

  • KV_SYNC_FLUSH

    Write and synchronously flush the log on transaction commit.

  • KV_SYNC_WRITE_NO_SYNC

    Write but do not synchronously flush the log on transaction commit.