BatchPolicy Class

Aerospike
Batch parent policy.
Inheritance Hierarchy

SystemObject
  Aerospike.ClientPolicy
    Aerospike.ClientBatchPolicy

Namespace:  Aerospike.Client
Assembly:  AerospikeClient (in AerospikeClient.dll) Version: 5.1.1.0 (5.1.1)
Syntax

C#
public sealed class BatchPolicy : Policy

The BatchPolicy type exposes the following members.

Constructors

  NameDescription
Public methodBatchPolicy
Default constructor.
Public methodBatchPolicy(BatchPolicy)
Copy batch policy from another batch policy.
Public methodBatchPolicy(Policy)
Copy batch policy from another policy.
Top
Methods

  NameDescription
Public methodStatic memberReadDefault
Default batch read policy.
Public methodSetTimeout
Create a single timeout by setting socketTimeout and totalTimeout to the same value.
(Inherited from Policy.)
Public methodSetTimeouts
Set socketTimeout and totalTimeout. If totalTimeout defined and socketTimeout greater than totalTimeout, set socketTimeout to totalTimeout.
(Inherited from Policy.)
Public methodStatic memberWriteDefault
Default batch write policy.
Top
Fields

  NameDescription
Public fieldallowInline
Allow batch to be processed immediately in the server's receiving thread for in-memory namespaces. If false, the batch will always be processed in separate service threads.

For batch transactions with smaller sized records (<= 1K per record), inline processing will be significantly faster on in-memory namespaces.

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 fieldallowInlineSSD
Allow batch to be processed immediately in the server's receiving thread for SSD namespaces. If false, the batch will always be processed in separate service threads. Server versions < 6.0 ignore this field.

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

Default: false

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.

Default: false

Public fieldcompress
Use zlib compression on command buffers sent to the server and responses received from the server when the buffer size is greater than 128 bytes.

This option will increase cpu and memory usage (for extra compressed buffers), but decrease the size of data sent over the network.

Default: false

(Inherited from Policy.)
Public fieldfailOnFilteredOut
Throw exception if filterExp is defined and that filter evaluates to false (transaction ignored). The AerospikeException will contain result code .

This field is not applicable to batch, scan or query commands.

Default: false

(Inherited from Policy.)
Public fieldCode examplefilterExp
Optional expression filter. If filterExp exists and evaluates to false, the transaction is ignored.

Default: null

(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 nodes requested and maxConcurrentThreads is 8, then batch requests will be made for 8 nodes in parallel threads. When a request completes, a new request will be issued until all 16 requests 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.

Default: 1

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

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 for read: 2 (initial attempt + 2 retries = 3 attempts)

Default for write: 0 (no retries)

Default for partition scan or query with null filter: 5 (6 attempts. See ScanPolicy comments.)

No default for legacy scan/query. No retries are allowed for these commands.

(Inherited from Policy.)
Public fieldreadModeAP
Read policy for AP (availability) namespaces.

Default: ONE

(Inherited from Policy.)
Public fieldreadModeSC
Read policy for SC (strong consistency) namespaces.

Default: SESSION

(Inherited from Policy.)
Public fieldrecordParser
Alternate record parser.

Default: Use standard record parser.

(Inherited from Policy.)
Public fieldreplica
Replica algorithm used to determine the target node for a single record command. Scan and query are not affected by replica algorithms.

Default: SEQUENCE

(Inherited from Policy.)
Public fieldrespondAllKeys
Should all batch keys be attempted regardless of errors. This field is used on both the client and server. The client handles node specific errors and the server handles key specific errors.

If true, every batch key is attempted regardless of previous key specific errors. Node specific errors such as timeouts stop keys to that node, but keys directed at other nodes will continue to be processed.

If false, the server will stop the batch to its node on most key specific errors. The exceptions are KEY_NOT_FOUND_ERROR and FILTERED_OUT which never stop the batch. The client will stop the entire batch on node specific errors for sync commands that are run in sequence (maxConcurrentThreads == 1). The client will not stop the entire batch for async commands or sync commands run in parallel.

Server versions < 6.0 do not support this field and treat this value as false for key specific errors.

Default: true

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 Obsolete.
This field is deprecated and will eventually be removed. The set name is now always sent for every distinct namespace/set in the batch.
Public fieldsleepBetweenRetries
Milliseconds to sleep between retries. Enter zero to skip sleep. This field is ignored when maxRetries is zero. This field is also ignored in async mode.

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.

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.

The default for writes is also zero because writes are not retried by default. 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. If maxRetries is greater than zero on a write, then sleepBetweenRetries should be set high enough to allow the cluster to reform (>= 3000ms).

Default: 0 (do not sleep between retries)

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

If socketTimeout is zero and totalTimeout is non-zero, then socketTimeout will be set to totalTimeout. If both socketTimeout and totalTimeout are non-zero and socketTimeout > totalTimeout, then socketTimeout will be set to totalTimeout. If both socketTimeout and totalTimeout are zero, then there will be no socket idle limit.

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.

For synchronous methods, socketTimeout is the socket SendTimeout and ReceiveTimeout. For asynchronous methods, the socketTimeout is implemented using the AsyncTimeoutQueue and socketTimeout is only used if totalTimeout is not defined.

Default: 30000ms

(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 AerospikeExceptionTimeout.

If totalTimeout is zero, there will be no total time limit.

Default: 0 (no time limit)

(Inherited from Policy.)
Top
See Also

Reference