BatchPolicy FieldsAerospike
The BatchPolicy type exposes the following members.
Fields

  NameDescription
Public fieldallowInline
Allow batch to be processed immediately in the server's receiving thread when the server deems it to be appropriate. If false, the batch will always be processed in separate transaction threads. This field is only relevant for the new batch index protocol.

For batch exists or batch reads of smaller sized records (less than 1K per record), inline processing will be significantly faster on "in memory" namespaces. The server disables inline processing on disk based namespaces regardless of this policy field.

Inline processing can introduce the possibility of unfairness because the server can process the entire batch before moving onto the next command. Default: true

Public fieldallowProleReads
Allow read operations to use replicated data partitions instead of master partition. By default, both read and write operations are directed to the master partition.

This variable is currently only used in batch read/exists operations. For batch, this variable should only be set to true when the replication factor is greater than or equal to the number of nodes in the cluster.

Public fieldconsistencyLevel
How replicas should be consulted in a read operation to provide the desired consistency guarantee.

Default: CONSISTENCY_ONE

(Inherited from Policy.)
Public fieldlinearizeRead
Force reads to be linearized for server namespaces that support CP mode.

Default: false

(Inherited from Policy.)
Public fieldmaxConcurrentThreads
Maximum number of concurrent synchronous batch request threads to server nodes at any point in time. If there are 16 node/namespace combinations requested and maxConcurrentThreads is 8, then batch requests will be made for 8 node/namespace combinations in parallel threads. When a request completes, a new request will be issued until all 16 threads are complete.

Values:

  • 1: Issue batch requests sequentially. This mode has a performance advantage for small to medium sized batch sizes because requests can be issued in the main transaction thread. This is the default.
  • 0: Issue all batch requests in parallel threads. This mode has a performance advantage for extremely large batch sizes because each node can process the request immediately. The downside is extra threads will need to be created (or taken from a thread pool).
  • > 0: Issue up to maxConcurrentThreads batch requests in parallel threads. When a request completes, a new request will be issued until all threads are complete. This mode prevents too many parallel threads being created for large cluster implementations. The downside is extra threads will still need to be created (or taken from a thread pool).

Asynchronous batch requests ignore this field and always issue all node requests in parallel.
Public fieldmaxRetries
Maximum number of retries before aborting the current transaction. The initial attempt is not counted as a retry.

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)

(Inherited from Policy.)
Public fieldpriority
Priority of request relative to other transactions. Currently, only used for scans.
(Inherited from Policy.)
Public fieldreplica
Replica algorithm used to determine the target node for a single record command. Batch, scan and query are not affected by replica algorithms.

Default: SEQUENCE

(Inherited from Policy.)
Public fieldsendKey
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.

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

(Inherited from Policy.)
Public fieldsendSetName
Send set name field to server for every key in the batch for batch index protocol. This is only necessary when authentication is enabled and security roles are defined on a per set basis. Default: false
Public fieldsleepBetweenRetries
Milliseconds to sleep between retries. Enter zero to skip sleep.

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 

(Inherited from Policy.)
Public fieldsocketTimeout
Socket idle timeout in milliseconds when processing a database command.

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).

(Inherited from Policy.)
Public fieldtotalTimeout
Total transaction timeout in milliseconds.

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).

(Inherited from Policy.)
Public fielduseBatchDirect
Use old batch direct protocol where batch reads are handled by direct low-level batch server database routines. The batch direct protocol can be faster when there is a single namespace, but there is one important drawback. The batch direct protocol will not proxy to a different server node when the mapped node has migrated a record to another node (resulting in not found record).

This can happen after a node has been added/removed from the cluster and there is a lag between records being migrated and client partition map update (once per second).

The new batch index protocol will perform this record proxy when necessary. Default: false (use new batch index protocol if server supports it)

Back to Top
See Also