Enum foundationdb::options::TransactionOption

#[non_exhaustive]pub enum TransactionOption {
    CausalWriteRisky,
    CausalReadRisky,
    CausalReadDisable,
    IncludePortInAddress,
    NextWriteNoWriteConflictRange,
    ReadYourWritesDisable,
    ReadAheadDisable,
    DurabilityDatacenter,
    DurabilityRisky,
    DurabilityDevNullIsWebScale,
    PrioritySystemImmediate,
    PriorityBatch,
    InitializeNewDatabase,
    AccessSystemKeys,
    ReadSystemKeys,
    DebugRetryLogging(String),
    TransactionLoggingEnable(String),
    DebugTransactionIdentifier(String),
    LogTransaction,
    TransactionLoggingMaxFieldLength(i32),
    Timeout(i32),
    RetryLimit(i32),
    MaxRetryDelay(i32),
    SizeLimit(i32),
    SnapshotRywEnable,
    SnapshotRywDisable,
    LockAware,
    UsedDuringCommitProtectionDisable,
    ReadLockAware,
    UseProvisionalProxies,
}

Variants (Non-exhaustive)

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

CausalWriteRisky

The transaction, if not self-conflicting, may be committed a second time after commit succeeds, in the event of a fault

CausalReadRisky

The read version will be committed, and usually will be the latest committed, but might not be the latest committed in the event of a simultaneous fault and misbehaving clock.

CausalReadDisable

IncludePortInAddress

Addresses returned by get_addresses_for_key include the port when enabled. This will be enabled by default in api version 630, and this option will be deprecated.

NextWriteNoWriteConflictRange

The next write performed on this transaction will not generate a write conflict range. As a result, other transactions which read the key(s) being modified by the next write will not conflict with this transaction. Care needs to be taken when using this option on a transaction that is shared between multiple threads. When setting this option, write conflict ranges will be disabled on the next write operation, regardless of what thread it is on.

ReadYourWritesDisable

Reads performed by a transaction will not see any prior mutations that occured in that transaction, instead seeing the value which was in the database at the transaction's read version. This option may provide a small performance benefit for the client, but also disables a number of client-side optimizations which are beneficial for transactions which tend to read and write the same keys within a single transaction.

ReadAheadDisable

Deprecated

DurabilityDatacenter

DurabilityRisky

DurabilityDevNullIsWebScale

Deprecated

PrioritySystemImmediate

Specifies that this transaction should be treated as highest priority and that lower priority transactions should block behind this one. Use is discouraged outside of low-level tools

PriorityBatch

Specifies that this transaction should be treated as low priority and that default priority transactions will be processed first. Batch priority transactions will also be throttled at load levels smaller than for other types of transactions and may be fully cut off in the event of machine failures. Useful for doing batch work simultaneously with latency-sensitive work

InitializeNewDatabase

This is a write-only transaction which sets the initial configuration. This option is designed for use by database system tools only.

AccessSystemKeys

Allows this transaction to read and modify system keys (those that start with the byte 0xFF)

ReadSystemKeys

Allows this transaction to read system keys (those that start with the byte 0xFF)

DebugRetryLogging(String)

Optional transaction name

TransactionLoggingEnable(String)

String identifier to be used in the logs when tracing this transaction. The identifier must not exceed 100 characters.

Deprecated

DebugTransactionIdentifier(String)

String identifier to be used when tracing or profiling this transaction. The identifier must not exceed 100 characters.

Sets a client provided identifier for the transaction that will be used in scenarios like tracing or profiling. Client trace logging or transaction profiling must be separately enabled.

LogTransaction

Enables tracing for this transaction and logs results to the client trace logs. The DEBUG_TRANSACTION_IDENTIFIER option must be set before using this option, and client trace logging must be enabled to get log output.

TransactionLoggingMaxFieldLength(i32)

Maximum length of escaped key and value fields.

Sets the maximum escaped length of key and value fields to be logged to the trace file via the LOG_TRANSACTION option, after which the field will be truncated. A negative value disables truncation.

Timeout(i32)

value in milliseconds of timeout

Set a timeout in milliseconds which, when elapsed, will cause the transaction automatically to be cancelled. Valid parameter values are [0, INT_MAX]. If set to 0, will disable all timeouts. All pending and any future uses of the transaction will throw an exception. The transaction can be used again after it is reset. Prior to API version 610, like all other transaction options, the timeout must be reset after a call to onError. If the API version is 610 or greater, the timeout is not reset after an onError call. This allows the user to specify a longer timeout on specific transactions than the default timeout specified through the transaction_timeout database option without the shorter database timeout cancelling transactions that encounter a retryable error. Note that at all API versions, it is safe and legal to set the timeout each time the transaction begins, so most code written assuming the older behavior can be upgraded to the newer behavior without requiring any modification, and the caller is not required to implement special logic in retry loops to only conditionally set this option.

RetryLimit(i32)

number of times to retry

Set a maximum number of retries after which additional calls to onError will throw the most recently seen error code. Valid parameter values are [-1, INT_MAX]. If set to -1, will disable the retry limit. Prior to API version 610, like all other transaction options, the retry limit must be reset after a call to onError. If the API version is 610 or greater, the retry limit is not reset after an onError call. Note that at all API versions, it is safe and legal to set the retry limit each time the transaction begins, so most code written assuming the older behavior can be upgraded to the newer behavior without requiring any modification, and the caller is not required to implement special logic in retry loops to only conditionally set this option.

MaxRetryDelay(i32)

value in milliseconds of maximum delay

Set the maximum amount of backoff delay incurred in the call to onError if the error is retryable. Defaults to 1000 ms. Valid parameter values are [0, INT_MAX]. If the maximum retry delay is less than the current retry delay of the transaction, then the current retry delay will be clamped to the maximum retry delay. Prior to API version 610, like all other transaction options, the maximum retry delay must be reset after a call to onError. If the API version is 610 or greater, the retry limit is not reset after an onError call. Note that at all API versions, it is safe and legal to set the maximum retry delay each time the transaction begins, so most code written assuming the older behavior can be upgraded to the newer behavior without requiring any modification, and the caller is not required to implement special logic in retry loops to only conditionally set this option.

SizeLimit(i32)

value in bytes

Set the transaction size limit in bytes. The size is calculated by combining the sizes of all keys and values written or mutated, all key ranges cleared, and all read and write conflict ranges. (In other words, it includes the total size of all data included in the request to the cluster to commit the transaction.) Large transactions can cause performance problems on FoundationDB clusters, so setting this limit to a smaller value than the default can help prevent the client from accidentally degrading the cluster's performance. This value must be at least 32 and cannot be set to higher than 10,000,000, the default transaction size limit.

SnapshotRywEnable

Snapshot read operations will see the results of writes done in the same transaction. This is the default behavior.

SnapshotRywDisable

Snapshot read operations will not see the results of writes done in the same transaction. This was the default behavior prior to API version 300.

LockAware

The transaction can read and write to locked databases, and is responsible for checking that it took the lock.

UsedDuringCommitProtectionDisable

By default, operations that are performed on a transaction while it is being committed will not only fail themselves, but they will attempt to fail other in-flight operations (such as the commit) as well. This behavior is intended to help developers discover situations where operations could be unintentionally executed after the transaction has been reset. Setting this option removes that protection, causing only the offending operation to fail.

ReadLockAware

The transaction can read from locked databases.

UseProvisionalProxies

This option should only be used by tools which change the database configuration.

Implementations

impl TransactionOption

pub fn code(&self) -> FDBTransactionOption

pub unsafe fn apply(&self, target: *mut FDBTransaction) -> FdbResult<()>

Trait Implementations

impl Clone for TransactionOption

fn clone(&self) -> TransactionOption

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for TransactionOption

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.