WritePolicy MembersAerospike

The WritePolicy type exposes the following members.
Constructors

  NameDescription
Public methodWritePolicy 
Default constructor.
Public methodWritePolicy(Policy)
Copy write policy from another policy.
Public methodWritePolicy(WritePolicy)
Copy write policy from another write policy.
Back to Top
Fields

  NameDescription
Public fieldcommitLevel
Desired consistency guarantee when committing a transaction on the server. The default (COMMIT_ALL) indicates that the server should wait for master and all replica commits to be successful before returning success to the client.
Public fieldconsistencyLevel
How replicas should be consulted in a read operation to provide the desired consistency guarantee.

Default: CONSISTENCY_ONE

(Inherited from Policy.)
Public fielddurableDelete
If the transaction results in a record deletion, leave a tombstone for the record. This prevents deleted records from reappearing after node failures. Valid for Aerospike Server Enterprise Edition 3.10+ only.

Default: false (do not tombstone deleted records).

Public fieldexpiration
Record expiration. Also known as ttl (time to live). Seconds record will live before being removed by the server.

Expiration values:

  • -2: Do not change ttl when record is updated. Supported by Aerospike server versions >= 3.10.1.
  • -1: Never expire. Supported by Aerospike server versions >= 3.1.4.
  • 0: Default to namespace's "default-ttl" on the server.
  • > 0: Actual ttl in seconds.

Public fieldgeneration
Expected generation. Generation is the number of times a record has been modified (including creation) on the server. If a write operation is creating a record, the expected generation would be 0.
Public fieldgenerationPolicy
Qualify how to handle record writes based on record generation. The default (NONE) indicates that the generation is not used to restrict writes.
Public fieldmaxRetries
Maximum number of retries before aborting the current transaction. A retry may be attempted when there is a network error. If maxRetries is exceeded, the abort will occur even if the timeout has not yet been exceeded.

Default: 1

(Inherited from Policy.)
Public fieldpriority
Priority of request relative to other transactions. Currently, only used for scans.
(Inherited from Policy.)
Public fieldrecordExistsAction
Qualify how to handle writes where the record already exists.
Public fieldreplica
Send read commands to the node containing the key's partition replica type. Write commands are not affected by this setting, because all writes are directed to the node containing the key's master partition.

Default: MASTER

(Inherited from Policy.)
Public fieldrespondAllOps
For client operate(), return a result for every operation.

Some operations do not return results by default (ListOperation.clear() for example). This can make it difficult to determine the desired result offset in the returned bin's result list.

Setting respondAllOps to true makes it easier to identify the desired result offset (result offset equals bin's operate sequence). If there is a map operation in operate(), respondAllOps will be forced to true for that operate() call.

Default: false

Public fieldretryOnTimeout
Should the client retry a command if the timeout is reached.

If false, throw timeout exception when the timeout has been reached. Note that retries can still occur if a command fails on a network error before the timeout has been reached.

If true, retry command with same timeout when the timeout has been reached. The maximum number of retries is defined by maxRetries.

Default: false
(Inherited from Policy.)
Public fieldsendKey
Send user defined key in addition to hash digest on both reads and writes.

Default: false (do not send the user defined key)

(Inherited from Policy.)
Public fieldsleepBetweenRetries
Milliseconds to sleep between retries. Do not sleep at all if zero. Used by synchronous commands only.

Default: 500ms

(Inherited from Policy.)
Public fieldtimeout
Total transaction timeout in milliseconds for both client and server. The timeout is tracked on the client and also sent to the server along with the transaction in the wire protocol. The client will most likely timeout first, but the server has the capability to timeout the transaction as well.

The timeout is also used as a socket timeout. Default: 0 (no timeout).

(Inherited from Policy.)
Back to Top
See Also