Struct Transaction

pub struct Transaction { /* private fields */ }

In FoundationDB, a transaction is a mutable snapshot of a database.

All read and write operations on a transaction see and modify an otherwise-unchanging version of the database and only change the underlying database if and when the transaction is committed. Read operations do see the effects of previous write operations on the same transaction. Committing a transaction usually succeeds in the absence of conflicts.

Applications must provide error handling and an appropriate retry loop around the application code for a transaction. See the documentation for fdb_transaction_on_error().

Transactions group operations into a unit with the properties of atomicity, isolation, and durability. Transactions also provide the ability to maintain an application’s invariants or integrity constraints, supporting the property of consistency. Together these properties are known as ACID.

Transactions are also causally consistent: once a transaction has been successfully committed, all subsequently created transactions will see the modifications made by it.

Implementations

impl Transaction

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.

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.

pub fn clear_client_budget(&self)

Removes every client-side limit of this transaction.

Accounting keeps running: only the limits are dropped.

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.

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

Called to set an option on an FDBTransaction.

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.

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

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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

pub fn commit( self, ) -> impl Future<Output = Result<TransactionCommitted, TransactionCommitError>> + Send + Sync + Unpin

Attempts to commit the sets and clears previously applied to the database snapshot represented by transaction to the actual database.

The commit may or may not succeed – in particular, if a conflicting transaction previously committed, then the commit must fail in order to preserve transactional isolation. If the commit does succeed, the transaction is durably committed to the database and all subsequently started transactions will observe its effects.

It is not necessary to commit a read-only transaction – you can simply drop it.

Callers will usually want to retry a transaction if the commit or a another method on the transaction returns a retryable error (see on_error and/or Database::transact).

As with other client/server databases, in some failure scenarios a client may be unable to determine whether a transaction succeeded. In these cases, Transaction::commit will return an error and is_maybe_committed() will returns true on that error. The on_error function treats this error as retryable, so retry loops that don’t check for is_maybe_committed() could execute the transaction twice. In these cases, you must consider the idempotence of the transaction. For more information, see Transactions with unknown results.

Normally, commit will wait for outstanding reads to return. However, if those reads were snapshot reads or the transaction option for disabling “read-your-writes” has been invoked, any outstanding reads will immediately return errors.

On an instrumented transaction, the commit ends the current attempt: its duration is recorded whatever the result, and a successful commit pushes the attempt to the metrics report as AttemptOutcome::Committed.

pub fn on_error( self, err: FdbError, ) -> impl Future<Output = FdbResult<Transaction>> + Send + Sync + Unpin

Implements the recommended retry and backoff behavior for a transaction. This function knows which of the error codes generated by other Transaction functions represent temporary error conditions and which represent application errors that should be handled by the application. It also implements an exponential backoff strategy to avoid swamping the database cluster with excessive retries when there is a high level of conflict between transactions.

It is not necessary to call reset() when handling an error with on_error() since the transaction has already been reset.

You should not call this method most of the times and use Database::transact which implements a retry loop strategy for you.

On success the transaction enters a new attempt: its usage restarts from zero, while its client budget is kept.

pub fn cancel(self) -> TransactionCancelled

Cancels the transaction. All pending or future uses of the transaction will return a transaction_cancelled error. The transaction can be used again after it is reset.

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");

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.

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.

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.

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.

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.

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.

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.

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.

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

pub fn update_metadata_version(&self)

pub fn reset(&mut self)

Reset transaction to its initial state.

In order to protect against a race condition with cancel(), this call require a mutable access to the transaction.

This is similar to dropping the transaction and creating a new one.

It is not necessary to call reset() when handling an error with on_error() since the transaction has already been reset.

This starts a new attempt: the usage restarts from zero, while the client budget is kept. On an instrumented transaction, the attempt being recorded is abandoned rather than reported: it reached no conclusion.

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.

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.

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.

Errors

Returns an FdbError if the special keyspace read fails.

pub fn add_conflict_range( &self, begin: &[u8], end: &[u8], ty: ConflictRangeType, ) -> FdbResult<()>

Adds a conflict range to a transaction without performing the associated read or write.

Note

Most applications will use the serializable isolation that transactions provide by default and will not need to manipulate conflict ranges.

impl Transaction

pub fn clear_subspace_range(&self, subspace: &Subspace)

Trait Implementations

impl Debug for Transaction

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

Formats the value using the given formatter.

impl Drop for Transaction

fn drop(&mut self)

Executes the destructor for this type.

impl From<TransactionCancelled> for Transaction

fn from(tc: TransactionCancelled) -> Transaction

Converts to this type from the input type.

impl From<TransactionCommitted> for Transaction

fn from(tc: TransactionCommitted) -> Transaction

Converts to this type from the input type.

impl Send for Transaction

impl Sync for Transaction