Name | Description | |
---|---|---|
![]() | BatchPolicy |
Default constructor.
|
![]() | BatchPolicy(BatchPolicy) |
Copy batch policy from another batch policy.
|
![]() | BatchPolicy(Policy) |
Copy batch policy from another policy.
|
Name | Description | |
---|---|---|
![]() | allowInline |
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 |
![]() | allowProleReads |
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. |
![]() | consistencyLevel |
How replicas should be consulted in a read operation to provide the desired
consistency guarantee.
(Inherited from Policy.)Default: CONSISTENCY_ONE |
![]() | maxConcurrentThreads |
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:
|
![]() | maxRetries |
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.
(Inherited from Policy.)Default: 1 |
![]() | priority |
Priority of request relative to other transactions.
Currently, only used for scans.
(Inherited from Policy.) |
![]() | replica |
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.
(Inherited from Policy.)Default: MASTER |
![]() | retryOnTimeout |
Should the client retry a command if the timeout is reached.
(Inherited from Policy.)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 |
![]() | sendKey |
Send user defined key in addition to hash digest on both reads and writes.
(Inherited from Policy.)Default: false (do not send the user defined key) |
![]() | sendSetName |
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
|
![]() | sleepBetweenRetries |
Milliseconds to sleep between retries. Do not sleep at all if zero.
Used by synchronous commands only.
(Inherited from Policy.)Default: 500ms |
![]() | timeout |
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.
(Inherited from Policy.)The timeout is also used as a socket timeout. Default: 0 (no timeout). |
![]() | useBatchDirect |
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) |