kv_create_time_consistency()

#include <kvstore.h>

kv_error_t 
kv_create_time_consistency(kv_consistency_t **consistency,
                           kv_timeout_t time_lag,
                           kv_timeout_t timeout_ms) 

Creates a consistency policy which describes the amount of time the replica is allowed to lag the master. The application can use this policy to ensure that the replica node sees all transactions that were committed on the master before the lag interval.

You release the memory allocated for the consistency structure using kv_release_consistency().

Effective use of this policy requires that the clocks on the master and replica are synchronized by using a protocol like NTP.

Parameters

• consistency

  The consistency parameter references memory into which a pointer to the allocated consistency policy is copied.

• time_lag

  The time_lag parameter specifies the time interval, in milliseconds, by which the replica may be out of date with respect to the master when a transaction is initiated on the replica.

• timeout_ms

  The timeout_ms parameter describes how long a replica may wait for the desired consistency to be achieved before giving up.

  To satisfied the consistency policy, the KVStore client driver implements a read operation by choosing a node (usually a replica) from the proper replication group, and sending it a request. If the replica cannot guarantee the desired Consistency within the Consistency timeout, it replies to the request with a failure indication. If there is still time remaining within the operation timeout, the client driver picks another node and tries the request again (transparent to the application).

  KVStore operations which accept a consistency policy also accept a separate operation timeout. It makes sense to think of the operation timeout as the maximum amount of time the application is willing to wait for the operation to complete. On the other hand, the consistency timeout is like a performance hint to the implementation, suggesting that it can generally expect a healthy replica to become consistent within the given amount of time, and that if it does not, then it is probably more likely worth the overhead of abandoning the request attempt and retrying with a different replica. Note that for the consistency timeout to be meaningful, it must be smaller than the operation timeout.

  Choosing a value for the operation timeout depends on the needs of the application. Finding a good consistency timeout value is more likely to depend on observations made of real system performance.

See Also

• Durability and Consistency Management Functions