Name | Description | |
---|---|---|
![]() | commitLevel |
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.
|
![]() | consistencyLevel |
How replicas should be consulted in a read operation to provide the desired
consistency guarantee.
(Inherited from Policy.)Default: CONSISTENCY_ONE |
![]() | durableDelete |
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). |
![]() | expiration |
Record expiration. Also known as ttl (time to live).
Seconds record will live before being removed by the server.
Expiration values:
|
![]() | generation |
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.
|
![]() | generationPolicy |
Qualify how to handle record writes based on record generation. The default (NONE)
indicates that the generation is not used to restrict writes.
|
![]() | linearizeRead |
Force reads to be linearized for server namespaces that support CP mode.
(Inherited from Policy.)Default: false |
![]() | maxRetries |
Maximum number of retries before aborting the current transaction.
The initial attempt is not counted as a retry.
(Inherited from Policy.)If maxRetries is exceeded, the transaction will abort with AerospikeException Timeout. WARNING: Database writes that are not idempotent (such as Add()) should not be retried because the write operation may be performed multiple times if the client timed out previous transaction attempts. It's important to use a distinct WritePolicy for non-idempotent writes which sets maxRetries = 0; Default: 2 (initial attempt + 2 retries = 3 attempts) |
![]() | priority |
Priority of request relative to other transactions.
Currently, only used for scans.
(Inherited from Policy.) |
![]() | recordExistsAction |
Qualify how to handle writes where the record already exists.
|
![]() | replica |
Replica algorithm used to determine the target node for a single record command.
Batch, scan and query are not affected by replica algorithms.
(Inherited from Policy.)Default: SEQUENCE |
![]() | respondAllOps |
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 |
![]() | sendKey |
Send user defined key in addition to hash digest on both reads and writes.
If the key is sent on a write, the key will be stored with the record on
the server.
(Inherited from Policy.)Default: false (do not send the user defined key) |
![]() | sleepBetweenRetries |
Milliseconds to sleep between retries. Enter zero to skip sleep.
(Inherited from Policy.)The sleep only occurs on connection errors and server timeouts which suggest a node is down and the cluster is reforming. The sleep does not occur when the client's socketTimeout expires. This field is ignored in async mode. Reads do not have to sleep when a node goes down because the cluster does not shut out reads during cluster reformation. The default for reads is zero. Writes need to wait for the cluster to reform when a node goes down. Immediate write retries on node failure have been shown to consistently result in errors. The default for writes is 500ms. This default is implemented in ClientPolicy |
![]() | socketTimeout |
Socket idle timeout in milliseconds when processing a database command.
(Inherited from Policy.)If socketTimeout is not zero and the socket has been idle for at least socketTimeout, both maxRetries and totalTimeout are checked. If maxRetries and totalTimeout are not exceeded, the transaction is retried. If both socketTimeout and totalTimeout are non-zero and socketTimeout > totalTimeout, then socketTimeout will be set to totalTimeout. If socketTimeout is zero, there will be no socket idle limit. For synchronous methods, socketTimeout is the socket SendTimeout and ReceiveTimeout. For asynchronous methods, the socketTimeout is implemented using an AsyncTimeoutQueue and socketTimeout is only used if totalTimeout is not defined. Default: 0 (no socket idle time limit). |
![]() | totalTimeout |
Total transaction timeout in milliseconds.
(Inherited from Policy.)The totalTimeout is tracked on the client and sent to the server along with the transaction in the wire protocol. The client will most likely timeout first, but the server also has the capability to timeout the transaction. If totalTimeout is not zero and totalTimeout is reached before the transaction completes, the transaction will abort with AerospikeException Timeout. If totalTimeout is zero, there will be no total time limit. Default: 0 (no time limit). |