Constructor
new BatchPolicy(propsopt)
- Description:
Initializes a new BatchPolicy from the provided policy values.
- Source:
- Since:
- v3.0.0
Parameters:
| Name | Type | Attributes | Description |
|---|---|---|---|
props |
Object |
<optional> |
Policy values |
Extends
Members
allowInline :boolean
- Description:
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.
- Source:
- Default Value:
true
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.
Type:
- boolean
allowInline :boolean
- Description:
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.
- Source:
- Default Value:
true
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.
Type:
- boolean
allowInlineSSD :boolean
- Description:
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.
- Source:
- Default Value:
false
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.
Type:
- boolean
allowInlineSSD :boolean
- Description:
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.
- Source:
- Default Value:
false
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.
Type:
- boolean
compress :boolean
- Description:
Use zlib compression on write or batch read commands when the command buffer size is greater than 128 bytes. In addition, tell the server to compress it's response on read commands. The server response compression threshold is also 128 bytes.
This option will increase cpu and memory usage (for extra compressed buffers), but decrease the size of data sent over the network.
Requires Enterprise Server version >= 4.8.
- Source:
- Since:
- v3.14.0
- Overrides:
Use zlib compression on write or batch read commands when the command buffer size is greater than 128 bytes. In addition, tell the server to compress it's response on read commands. The server response compression threshold is also 128 bytes.
This option will increase cpu and memory usage (for extra compressed buffers), but decrease the size of data sent over the network.
Requires Enterprise Server version >= 4.8.
Type:
- boolean
concurrent :boolean
- Description:
Determine if batch commands to each server are run in parallel threads.
Values: false: Issue batch commands sequentially. This mode has a performance advantage for small to medium sized batch sizes because commands can be issued in the main transaction thread. This is the default. true: Issue batch commands in parallel threads. This mode has a performance advantage for large batch sizes because each node can process the command immediately. The downside is extra threads will need to be created (or taken from a thread pool).
- Source:
- Default Value:
false
Determine if batch commands to each server are run in parallel threads.
Values: false: Issue batch commands sequentially. This mode has a performance advantage for small to medium sized batch sizes because commands can be issued in the main transaction thread. This is the default. true: Issue batch commands in parallel threads. This mode has a performance advantage for large batch sizes because each node can process the command immediately. The downside is extra threads will need to be created (or taken from a thread pool).
Type:
- boolean
concurrent :boolean
- Description:
Determine if batch commands to each server are run in parallel threads.
Values: false: Issue batch commands sequentially. This mode has a performance advantage for small to medium sized batch sizes because commands can be issued in the main transaction thread. This is the default. true: Issue batch commands in parallel threads. This mode has a performance advantage for large batch sizes because each node can process the command immediately. The downside is extra threads will need to be created (or taken from a thread pool).
- Source:
- Default Value:
false
Determine if batch commands to each server are run in parallel threads.
Values: false: Issue batch commands sequentially. This mode has a performance advantage for small to medium sized batch sizes because commands can be issued in the main transaction thread. This is the default. true: Issue batch commands in parallel threads. This mode has a performance advantage for large batch sizes because each node can process the command immediately. The downside is extra threads will need to be created (or taken from a thread pool).
Type:
- boolean
deserialize :boolean
- Description:
Should CDT data types (Lists / Maps) be deserialized to JS data types (Arrays / Objects) or returned as raw bytes (Buffer).
- Source:
- Since:
- v3.7.0
- Default Value:
true
Should CDT data types (Lists / Maps) be deserialized to JS data types (Arrays / Objects) or returned as raw bytes (Buffer).
Type:
- boolean
deserialize :boolean
- Description:
Should CDT data types (Lists / Maps) be deserialized to JS data types (Arrays / Objects) or returned as raw bytes (Buffer).
- Source:
- Since:
- v3.7.0
- Default Value:
true
Should CDT data types (Lists / Maps) be deserialized to JS data types (Arrays / Objects) or returned as raw bytes (Buffer).
Type:
- boolean
filterExpression
- Description:
Optional expression filter. If filter exp exists and evaluates to false, the transaction is ignored. This can be used to eliminate a client/server roundtrip in some cases.
expression filters can only be applied to the following commands:
- Source:
- Overrides:
Optional expression filter. If filter exp exists and evaluates to false, the transaction is ignored. This can be used to eliminate a client/server roundtrip in some cases.
expression filters can only be applied to the following commands:
maxRetries :number
- Description:
Maximum number of retries before aborting the current transaction. The initial attempt is not counted as a retry.
If
maxRetriesis exceeded, the transaction will return errorERR_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 is important to use a distinct write policy for non-idempotent writes which sets
maxRetriesto zero.
- Source:
- Overrides:
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 return
error ERR_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 is important to use a distinct write policy for non-idempotent
writes which sets maxRetries to zero.
Type:
- number
readModeAP :number
- Description:
Read policy for AP (availability) namespaces.
- Source:
- Default Value:
- Aerospike.policy.readModeAP.ONE
- See:
-
module:aerospike/policy.readModeAPfor supported policy values.
Read policy for AP (availability) namespaces.
Type:
- number
readModeAP :number
- Description:
Read policy for AP (availability) namespaces.
- Source:
- Default Value:
- Aerospike.policy.readModeAP.ONE
- See:
-
module:aerospike/policy.readModeAPfor supported policy values.
Read policy for AP (availability) namespaces.
Type:
- number
readModeSC :number
- Description:
Read policy for SC (strong consistency) namespaces.
- Source:
- Default Value:
- Aerospike.policy.readModeSC.SESSION
- See:
-
module:aerospike/policy.readModeSCfor supported policy values.
Read policy for SC (strong consistency) namespaces.
Type:
- number
readModeSC :number
- Description:
Read policy for SC (strong consistency) namespaces.
- Source:
- Default Value:
- Aerospike.policy.readModeSC.SESSION
- See:
-
module:aerospike/policy.readModeSCfor supported policy values.
Read policy for SC (strong consistency) namespaces.
Type:
- number
replica :number
- Description:
Algorithm used to determine target node.
- Source:
- Default Value:
- Aerospike.policy.replica.MASTER
- See:
-
module:aerospike/policy.replicafor supported policy values.
Algorithm used to determine target node.
Type:
- number
replica :number
- Description:
Algorithm used to determine target node.
- Source:
- Default Value:
- Aerospike.policy.replica.MASTER
- See:
-
module:aerospike/policy.replicafor supported policy values.
Algorithm used to determine target node.
Type:
- number
respondAllKeys :boolean
- Description:
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 AEROSPIKE_ERR_RECORD_NOT_FOUND and AEROSPIKE_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 (concurrent == false). 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.
- Source:
- Default Value:
true
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 AEROSPIKE_ERR_RECORD_NOT_FOUND and AEROSPIKE_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 (concurrent == false). 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.
Type:
- boolean
respondAllKeys :boolean
- Description:
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 AEROSPIKE_ERR_RECORD_NOT_FOUND and AEROSPIKE_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 (concurrent == false). 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.
- Source:
- Default Value:
true
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 AEROSPIKE_ERR_RECORD_NOT_FOUND and AEROSPIKE_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 (concurrent == false). 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.
Type:
- boolean
sendSetName :boolean
- Description:
Send set name field to server for every key in the batch. This is only necessary when authentication is enabled and security roles are defined on a per-set basis.
- Source:
- Default Value:
false
Send set name field to server for every key in the batch. This is only necessary when authentication is enabled and security roles are defined on a per-set basis.
Type:
- boolean
sendSetName :boolean
- Description:
Send set name field to server for every key in the batch. This is only necessary when authentication is enabled and security roles are defined on a per-set basis.
- Source:
- Default Value:
false
Send set name field to server for every key in the batch. This is only necessary when authentication is enabled and security roles are defined on a per-set basis.
Type:
- boolean
socketTimeout :number
- Description:
Socket idle timeout in milliseconds when processing a database command.
If
socketTimeoutis not zero and the socket has been idle for at leastsocketTimeout, bothmaxRetriesandtotalTimeoutare checked. IfmaxRetriesandtotalTimeoutare not exceeded, the transaction is retried.If both
socketTimeoutandtotalTimeoutare non-zero andsocketTimeout>totalTimeout, thensocketTimeoutwill be set tototalTimeout. IfsocketTimeoutis zero, there will be no socket idle limit.
- Source:
- Overrides:
- Default Value:
- 0 (no socket idle time limit).
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.
Type:
- number
totalTimeout :number
- Description:
Total transaction timeout in milliseconds.
The
totalTimeoutis 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
totalTimeoutis not zero andtotalTimeoutis reached before the transaction completes, the transaction will return errorERR_TIMEOUT. IftotalTimeoutis zero, there will be no total time limit.
- Source:
- Overrides:
- Default Value:
- 1000
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 return
error ERR_TIMEOUT.
If totalTimeout is zero, there will be no total time limit.
Type:
- number