Struct google_cloud_spanner::transaction_rw::ReadWriteTransaction

pub struct ReadWriteTransaction { /* fields omitted */ }

ReadWriteTransaction provides a locking read-write transaction.

This type of transaction is the only way to write data into Cloud Spanner; Client::apply, Client::apply_at_least_once, Client::partitioned_update use transactions internally. These transactions rely on pessimistic locking and, if necessary, two-phase commit. Locking read-write transactions may abort, requiring the application to retry. However, the interface exposed by Client:run_with_retry eliminates the need for applications to write retry loops explicitly.

Locking transactions may be used to atomically read-modify-write data anywhere in a database. This type of transaction is externally consistent.

Clients should attempt to minimize the amount of time a transaction is active. Faster transactions commit with higher probability and cause less contention. Cloud Spanner attempts to keep read locks active as long as the transaction continues to do reads. Long periods of inactivity at the client may cause Cloud Spanner to release a transaction’s locks and abort it.

Reads performed within a transaction acquire locks on the data being read. Writes can only be done at commit time, after all reads have been completed. Conceptually, a read-write transaction consists of zero or more reads or SQL queries followed by a commit.

See Client::run_with_retry for an example.

Semantics

Cloud Spanner can commit the transaction if all read locks it acquired are still valid at commit time, and it is able to acquire write locks for all writes. Cloud Spanner can abort the transaction for any reason. If a commit attempt returns ABORTED, Cloud Spanner guarantees that the transaction has not modified any user data in Cloud Spanner.

Unless the transaction commits, Cloud Spanner makes no guarantees about how long the transaction’s locks were held for. It is an error to use Cloud Spanner locks for any sort of mutual exclusion other than between Cloud Spanner transactions themselves.

Aborted transactions

Application code does not need to retry explicitly; RunInTransaction will automatically retry a transaction if an attempt results in an abort. The lock priority of a transaction increases after each prior aborted transaction, meaning that the next attempt has a slightly better chance of success than before.

Under some circumstances (e.g., many transactions attempting to modify the same row(s)), a transaction can abort many times in a short period before successfully committing. Thus, it is not a good idea to cap the number of retries a transaction can attempt; instead, it is better to limit the total amount of wall time spent retrying.

Implementations

impl ReadWriteTransaction

pub async fn begin(
    session: ManagedSession,
    options: CallOptions
) -> Result<ReadWriteTransaction, BeginError>

pub async fn begin_partitioned_dml(
    session: ManagedSession,
    options: CallOptions
) -> Result<ReadWriteTransaction, BeginError>

pub fn buffer_write(&mut self, ms: Vec<Mutation>)

pub async fn update(&mut self, stmt: Statement) -> Result<i64, Status>

pub async fn update_with_option(
    &mut self,
    stmt: Statement,
    options: QueryOptions
) -> Result<i64, Status>

pub async fn batch_update(
    &mut self,
    stmt: Vec<Statement>
) -> Result<Vec<i64>, Status>

pub async fn batch_update_with_option(
    &mut self,
    stmt: Vec<Statement>,
    options: QueryOptions
) -> Result<Vec<i64>, Status>

pub async fn finish<T, E>(
    &mut self,
    result: Result<T, E>,
    options: Option<CommitOptions>
) -> Result<(Option<Timestamp>, T), (E, Option<ManagedSession>)> where
    E: TryAs<Status> + From<Status>, 

pub async fn commit(
    &mut self,
    options: CommitOptions
) -> Result<CommitResponse, Status>

pub async fn rollback(&mut self, setting: Option<BackoffRetrySettings>)

Methods from Deref<Target = Transaction>

pub async fn query(
    &mut self,
    statement: Statement
) -> Result<RowIterator<'_>, Status>

query executes a query against the database. It returns a RowIterator for retrieving the resulting rows.

query returns only row data, without a query plan or execution statistics.

pub async fn query_with_option(
    &mut self,
    statement: Statement,
    options: QueryOptions
) -> Result<RowIterator<'_>, Status>

query executes a query against the database. It returns a RowIterator for retrieving the resulting rows.

query returns only row data, without a query plan or execution statistics.

pub async fn read<T, C, K>(
    &mut self,
    table: T,
    columns: Vec<C>,
    key_set: K
) -> Result<RowIterator<'_>, Status> where
    T: Into<String>,
    C: Into<String>,
    K: Into<KeySet>, 

read returns a RowIterator for reading multiple rows from the database.

pub async fn read_with_option<T, C, K>(
    &mut self,
    table: T,
    columns: Vec<C>,
    key_set: K,
    options: ReadOptions
) -> Result<RowIterator<'_>, Status> where
    T: Into<String>,
    C: Into<String>,
    K: Into<KeySet>, 

read returns a RowIterator for reading multiple rows from the database.

pub async fn read_row<T, C>(
    &mut self,
    table: T,
    columns: Vec<C>,
    key: Key
) -> Result<Option<Row>, Status> where
    T: Into<String>,
    C: Into<String>, 

read returns a RowIterator for reading multiple rows from the database.

pub async fn read_row_with_option<T, C>(
    &mut self,
    table: T,
    columns: Vec<C>,
    key: Key,
    options: ReadOptions
) -> Result<Option<Row>, Status> where
    T: Into<String>,
    C: Into<String>, 

read returns a RowIterator for reading multiple rows from the database.

Trait Implementations

impl Deref for ReadWriteTransaction

type Target = Transaction

The resulting type after dereferencing.

fn deref(&self) -> &Self::Target

Dereferences the value.

impl DerefMut for ReadWriteTransaction

fn deref_mut(&mut self) -> &mut Transaction

Mutably dereferences the value.