Struct RetryableTransaction

Source

pub struct RetryableTransaction { /* private fields */ }

Expand description

A retryable transaction, generated by Database.run

Methods from Deref<Target = Transaction>§

Source

pub fn attempt_usage(&self) -> UsageSnapshot

Returns the usage accounted for the current transaction attempt.

Accounting is always on, no instrumentation needed. The counters are client-side estimates and are reset on every new attempt, see crate::budget.

Source

pub fn set_client_budget(&self, budget: ClientBudget)

Sets the client-side budget of this transaction.

The limits are not enforced by FoundationDB and not enforced automatically: they are checked when you call check_client_budget. See crate::budget for what is counted and how precise it is.

Setting a budget starts a fresh accounting generation, so the limits apply to what happens from now on. They then survive on_error and reset, and apply to each subsequent attempt with usage back at zero. That generation, and every later one, is measured with the clock of this budget.

On an instrumented transaction, set the budget before doing anything else: the new generation is also the one the metrics record into, so operations performed before this call are not reported.

Source

pub fn clear_client_budget(&self)

Removes every client-side limit of this transaction.

Accounting keeps running: only the limits are dropped.

Source

pub fn check_client_budget(&self) -> Result<(), BudgetExceeded>

Checks the usage of the current attempt against the client-side budget.

This is a synchronous, cheap check: a few atomic loads and one reading of the clock of the budget, the wall clock by default, no call to the database. Nothing calls it for you, so call it between the operations of your transaction, typically inside a Database::run closure where FdbBindingError makes ? work:

db.run(|trx, _| {
    let keys = keys.clone();
    async move {
        trx.set_client_budget(ClientBudget {
            max_bytes_read: Some(1024 * 1024),
            ..ClientBudget::default()
        });
        for key in keys {
            trx.get(&key, false).await?;
            trx.check_client_budget()?;
        }
        Ok::<_, FdbBindingError>(())
    }
})
.await?;

§Errors

Returns the first BudgetExceeded limit found, checked in order: time, bytes read, bytes written.

Source

pub fn set_option(&self, opt: TransactionOption) -> FdbResult<()>

Called to set an option on an FDBTransaction.

Source

pub fn set_raw_option( &self, code: FDBTransactionOption, data: Option<Vec<u8>>, ) -> FdbResult<()>

Pass through an option given a code and raw data. Useful when creating a passthrough layer where the code and data will be provided as raw, in order to avoid deserializing to an option and serializing it back to code and data. In general, you should use set_option.

Source

pub fn set(&self, key: &[u8], value: &[u8])

Modify the database snapshot represented by transaction to change the given key to have the given value.

If the given key was not previously present in the database it is inserted. The modification affects the actual database only if transaction is later committed with Transaction::commit.

§Arguments

key - the name of the key to be inserted into the database.
value - the value to be inserted into the database

Source

pub fn clear(&self, key: &[u8])

Modify the database snapshot represented by transaction to remove the given key from the database.

If the key was not previously present in the database, there is no effect. The modification affects the actual database only if transaction is later committed with Transaction::commit.

§Arguments

key - the name of the key to be removed from the database.

Source

pub fn get( &self, key: &[u8], snapshot: bool, ) -> impl Future<Output = FdbResult<Option<FdbSlice>>> + Send + Sync + Unpin + use<>

Reads a value from the database snapshot represented by transaction.

Returns an FDBFuture which will be set to the value of key in the database if there is any.

§Arguments

key - the name of the key to be looked up in the database
snapshot - true if this is a snapshot read

The attempt usage is recorded when the future resolves successfully, into the attempt that issued the read: a read still in flight is not visible to check_client_budget yet.

Source

pub fn atomic_op(&self, key: &[u8], param: &[u8], op_type: MutationType)

Modify the database snapshot represented by transaction to perform the operation indicated by operationType with operand param to the value stored by the given key.

An atomic operation is a single database command that carries out several logical steps: reading the value of a key, performing a transformation on that value, and writing the result. Different atomic operations perform different transformations. Like other database operations, an atomic operation is used within a transaction; however, its use within a transaction will not cause the transaction to conflict.

Atomic operations do not expose the current value of the key to the client but simply send the database the transformation to apply. In regard to conflict checking, an atomic operation is equivalent to a write without a read. It can only cause other transactions performing reads of the key to conflict.

By combining these logical steps into a single, read-free operation, FoundationDB can guarantee that the transaction will not conflict due to the operation. This makes atomic operations ideal for operating on keys that are frequently modified. A common example is the use of a key-value pair as a counter.

§Warning

If a transaction uses both an atomic operation and a strictly serializable read on the same key, the benefits of using the atomic operation (for both conflict checking and performance) are lost.

Source

pub fn get_key( &self, selector: &KeySelector<'_>, snapshot: bool, ) -> impl Future<Output = FdbResult<FdbSlice>> + Send + Sync + Unpin + use<>

Resolves a key selector against the keys in the database snapshot represented by transaction.

Returns an FDBFuture which will be set to the key in the database matching the key selector.

§Arguments

selector: the key selector
snapshot: true if this is a snapshot read

In the attempt usage, this counts as a get of the selector key plus the resolved key, recorded when the future resolves successfully.

Source

pub fn get_ranges<'a>( &'a self, opt: RangeOption<'a>, snapshot: bool, ) -> impl Stream<Item = FdbResult<FdbValues>> + Send + Sync + Unpin + 'a

Reads all key-value pairs in the database snapshot represented by transaction (potentially limited by limit, target_bytes, or mode) which have a key lexicographically greater than or equal to the key resolved by the begin key selector and lexicographically less than the key resolved by the end key selector.

Returns a stream of KeyValue slices.

This method is a little more efficient than get_ranges_keyvalues but a little harder to use.

§Arguments

opt: the range, limit, target_bytes and mode
snapshot: true if this is a snapshot read

Source

pub fn get_ranges_keyvalues<'a>( &'a self, opt: RangeOption<'a>, snapshot: bool, ) -> impl Stream<Item = FdbResult<FdbValue>> + Unpin + 'a

Reads all key-value pairs in the database snapshot represented by transaction (potentially limited by limit, target_bytes, or mode) which have a key lexicographically greater than or equal to the key resolved by the begin key selector and lexicographically less than the key resolved by the end key selector.

Returns a stream of KeyValue.

§Arguments

opt: the range, limit, target_bytes and mode
snapshot: true if this is a snapshot read

Source

pub fn get_range( &self, opt: &RangeOption<'_>, iteration: usize, snapshot: bool, ) -> impl Future<Output = FdbResult<FdbValues>> + Send + Sync + Unpin + use<>

Reads all key-value pairs in the database snapshot represented by transaction (potentially limited by limit, target_bytes, or mode) which have a key lexicographically greater than or equal to the key resolved by the begin key selector and lexicographically less than the key resolved by the end key selector.

This method returns only a single batch of results, not necessarily all key-value pairs in the range. It is a low-level primitive for manual pagination. Most callers should use get_ranges_keyvalues, which automatically pages through the full range and yields every key-value pair as a stream.

§Arguments

opt: the range, limit, target_bytes and mode
iteration: If opt.mode is Iterator, this parameter should start at 1 and be incremented by 1 for each successive call while reading this range. In all other cases it is ignored.
snapshot: true if this is a snapshot read

In the attempt usage, each resolved batch counts as one call_get_range: a full range scan through get_ranges counts once per underlying batch.

Source

pub fn get_mapped_range( &self, opt: &RangeOption<'_>, mapper: &[u8], iteration: usize, snapshot: bool, ) -> impl Future<Output = FdbResult<MappedKeyValues>> + Send + Sync + Unpin + use<>

Mapped Range is an experimental feature introduced in FDB 7.1. It is intended to improve the client throughput and reduce latency for querying data through a Subspace used as a “index”. In such a case, querying records by scanning an index in relational databases can be translated to a GetRange request on the index entries followed up by multiple GetValue requests for the record entries in FDB.

This method is allowing FoundationDB “follow up” a GetRange request with GetValue requests, this can happen in one request without additional back and forth. Considering the overhead of each request, this saves time and resources on serialization, deserialization, and network.

A mapped request will:

Do a range query (same as a Transaction.get_range request) and get the result. We call it the primary query.
For each key-value pair in the primary query result, translate it to a get_range query and get the result. We call them secondary queries.
Put all results in a nested structure and return them.

WARNING : This feature is considered experimental at this time. It is only allowed when using snapshot isolation AND disabling read-your-writes.

More info can be found in the relevant documentation.

This is the “raw” version, users are expected to use Transaction::get_mapped_ranges

In the attempt usage, a resolved batch counts as one call_get_range and as the bytes of the primary key-values plus the nested key-values returned by the secondary queries.

Source

pub fn get_mapped_ranges<'a>( &'a self, opt: RangeOption<'a>, mapper: &'a [u8], snapshot: bool, ) -> impl Stream<Item = FdbResult<MappedKeyValues>> + Send + Sync + Unpin + 'a

Mapped Range is an experimental feature introduced in FDB 7.1. It is intended to improve the client throughput and reduce latency for querying data through a Subspace used as a “index”. In such a case, querying records by scanning an index in relational databases can be translated to a GetRange request on the index entries followed up by multiple GetValue requests for the record entries in FDB.

This method is allowing FoundationDB “follow up” a GetRange request with GetValue requests, this can happen in one request without additional back and forth. Considering the overhead of each request, this saves time and resources on serialization, deserialization, and network.

A mapped request will:

Do a range query (same as a Transaction.get_range request) and get the result. We call it the primary query.
For each key-value pair in the primary query result, translate it to a get_range query and get the result. We call them secondary queries.
Put all results in a nested structure and return them.

WARNING : This feature is considered experimental at this time. It is only allowed when using snapshot isolation AND disabling read-your-writes.

More info can be found in the relevant documentation.

Source

pub fn clear_range(&self, begin: &[u8], end: &[u8])

Modify the database snapshot represented by transaction to remove all keys (if any) which are lexicographically greater than or equal to the given begin key and lexicographically less than the given end_key.

The modification affects the actual database only if transaction is later committed with Transaction::commit.

In the attempt usage, this counts as the two boundary keys only: the volume of data actually deleted is unknown to the client.

Source

pub fn get_estimated_range_size_bytes( &self, begin: &[u8], end: &[u8], ) -> impl Future<Output = FdbResult<i64>> + Send + Sync + Unpin + use<>

Get the estimated byte size of the key range based on the byte sample collected by FDB

Source

pub fn set_custom_metric(&self, name: &str, value: u64, labels: &[(&str, &str)])

Records an application metric for the current attempt, replacing any value previously recorded under the same name and labels.

Custom metrics are always on, like the usage counters, and scoped to the current attempt: a retry starts from an empty set, and the values of the attempt that ended stay attached to it in the report. Recording one on a transaction nobody collects metrics from is free of consequence: the values are dropped along with the attempt.

§Arguments

name - The name of the metric (e.g., “query_time”, “cache_hits”)
value - The value to record
labels - Key-value pairs for labeling the metric, allowing for dimensional metrics (e.g., [("operation", "read"), ("region", "us-west")])

§Example

let (_, metrics) = db
    .instrumented_run(|txn, _| async move {
        txn.set_custom_metric("documents_indexed", 42, &[("kind", "user")]);
        Ok::<_, FdbBindingError>(())
    })
    .await
    .map_err(|(err, _)| err)?;

// The values are attached to the attempt that recorded them.
let attempt = metrics.attempts.last().expect("one attempt");

Source

pub fn increment_custom_metric( &self, name: &str, amount: u64, labels: &[(&str, &str)], )

Adds amount to an application metric of the current attempt, starting from zero if it was not recorded yet.

Same per-attempt semantics as set_custom_metric.

§Arguments

name - The name of the metric to increment (e.g., “requests”, “bytes_processed”)
amount - The amount to increment the metric by
labels - Key-value pairs for labeling the metric, allowing for dimensional metrics (e.g., [("status", "success"), ("endpoint", "api/v1/users")])

§Example

let txn = db.create_trx()?;

txn.increment_custom_metric("cache_misses", 1, &[("cache", "user_data")]);
txn.increment_custom_metric("cache_misses", 1, &[("cache", "user_data")]);
// The metric of the current attempt is now 2.

Source

pub fn get_addresses_for_key( &self, key: &[u8], ) -> impl Future<Output = FdbResult<FdbAddresses>> + Send + Sync + Unpin + use<>

Returns a list of public network addresses as strings, one for each of the storage servers responsible for storing key_name and its associated value.

Source

pub fn watch( &self, key: &[u8], ) -> impl Future<Output = FdbResult<()>> + Send + Sync + Unpin + use<>

A watch’s behavior is relative to the transaction that created it. A watch will report a change in relation to the key’s value as readable by that transaction. The initial value used for comparison is either that of the transaction’s read version or the value as modified by the transaction itself prior to the creation of the watch. If the value changes and then changes back to its initial value, the watch might not report the change.

Until the transaction that created it has been committed, a watch will not report changes made by other transactions. In contrast, a watch will immediately report changes made by the transaction itself. Watches cannot be created if the transaction has set the READ_YOUR_WRITES_DISABLE transaction option, and an attempt to do so will return an watches_disabled error.

If the transaction used to create a watch encounters an error during commit, then the watch will be set with that error. A transaction whose commit result is unknown will set all of its watches with the commit_unknown_result error. If an uncommitted transaction is reset or destroyed, then any watches it created will be set with the transaction_cancelled error.

Returns an future representing an empty value that will be set once the watch has detected a change to the value at the specified key.

By default, each database connection can have no more than 10,000 watches that have not yet reported a change. When this number is exceeded, an attempt to create a watch will return a too_many_watches error. This limit can be changed using the MAX_WATCHES database option. Because a watch outlives the transaction that creates it, any watch that is no longer needed should be cancelled by dropping its future.

Source

pub fn get_approximate_size( &self, ) -> impl Future<Output = FdbResult<i64>> + Send + Sync + Unpin + use<>

Returns an FDBFuture which will be set to the approximate transaction size so far in the returned future, which is the summation of the estimated size of mutations, read conflict ranges, and write conflict ranges.

This can be called multiple times before the transaction is committed.

Source

pub fn get_range_split_points( &self, begin: &[u8], end: &[u8], chunk_size: i64, ) -> impl Future<Output = FdbResult<FdbKeys>> + Send + Sync + Unpin + use<>

Gets a list of keys that can split the given range into (roughly) equally sized chunks based on chunk_size. Note: the returned split points contain the start key and end key of the given range.

Source

pub fn get_versionstamp( &self, ) -> impl Future<Output = FdbResult<FdbSlice>> + Send + Sync + Unpin + use<>

Returns an FDBFuture which will be set to the versionstamp which was used by any versionstamp operations in this transaction.

The future will be ready only after the successful completion of a call to commit() on this Transaction. Read-only transactions do not modify the database when committed and will result in the future completing with an error. Keep in mind that a transaction which reads keys and then sets them to their current values may be optimized to a read-only transaction.

Most applications will not call this function.

Source

pub fn get_read_version( &self, ) -> impl Future<Output = FdbResult<i64>> + Send + Sync + Unpin + use<>

The transaction obtains a snapshot read version automatically at the time of the first call to get_*() (including this one) and (unless causal consistency has been deliberately compromised by transaction options) is guaranteed to represent all transactions which were reported committed before that call.

On an instrumented transaction, the version is recorded in the metrics of the current attempt. It is only ever recorded when this method is called: the binding never fetches a read version on its own.

Source

pub fn set_read_version(&self, version: i64)

Sets the snapshot read version used by a transaction.

This is not needed in simple cases. If the given version is too old, subsequent reads will fail with error_code_past_version; if it is too new, subsequent reads may be delayed indefinitely and/or fail with error_code_future_version. If any of get_*() have been called on this transaction already, the result is undefined.

Source

pub async fn get_metadata_version( &self, snapshot: bool, ) -> FdbResult<Option<i64>>

The metadata version key \xff/metadataVersion is a key intended to help layers deal with hot keys. The value of this key is sent to clients along with the read version from the proxy, so a client can read its value without communicating with a storage server. To retrieve the metadataVersion, you need to set TransactionOption::ReadSystemKeys

Source

pub fn update_metadata_version(&self)

Source

pub async fn conflicting_keys(&self) -> FdbResult<Vec<ConflictingKeyRange>>

Reads the conflicting key ranges from the special keyspace after a commit conflict.

This method reads from \xff\xff/transaction/conflicting_keys/ and parses the boundary encoding where b"1" marks range starts and b"0" marks range ends.

The special keyspace read is resolved client-side — no network round-trip to the cluster. The future still goes through the FDB network thread event loop, but the data comes from an in-memory map populated during the commit response. Returns an empty Vec if TransactionOption::ReportConflictingKeys was not set.

Requires API version 630 or later: the special keyspace does not exist on older versions, where this read fails.

Only complete ranges are returned. A begin marker whose end marker never arrives is dropped, identically in debug and release builds.

§Errors

Returns an FdbError if the special keyspace read fails.

Source

pub async fn read_conflict_ranges(&self) -> FdbResult<Vec<ConflictRange>>

Reads the read conflict ranges accumulated by this transaction so far.

These are the ranges the resolver will check for conflicts at commit time: every key read by the transaction, plus the ranges added with add_conflict_range. A point read of k shows up as k..k\x00.

Reading this keyspace waits for every pending read of the transaction to settle, since a read that has not returned yet has not registered its conflict range. Called in the middle of a batch of concurrent reads, it is therefore as slow as the slowest of them.

The read itself is performed by the binding on your behalf: it is not accounted in the attempt usage and does not consume the client budget.

Only complete ranges are returned, see conflicting_keys.

§Errors

Returns an FdbError if the special keyspace read fails.

Source

pub async fn write_conflict_ranges(&self) -> FdbResult<Vec<ConflictRange>>

Reads the write conflict ranges accumulated by this transaction so far.

These are the ranges the transaction will conflict other transactions on: every key it wrote, plus the ranges added with add_conflict_range. A single set of k shows up as k..k\x00.

Before the commit, this is an approximate superset of the final write conflict ranges when the transaction uses versionstamped keys: the versionstamp is only known at commit time, so the incomplete key is reported with its placeholder bytes.

The read itself is performed by the binding on your behalf: it is not accounted in the attempt usage and does not consume the client budget.

Only complete ranges are returned, see conflicting_keys.