Class DelayedAsyncTransactionManager (6.95.1)

Represents a AsyncTransactionManager using a multiplexed session that is not yet ready. The execution will be delayed until the multiplexed session has been created and is ready. This class is only used during the startup of the client and the multiplexed session has not yet been created.

Creates a new read write transaction. This must be called before doing any other operation and can only be called once. To create a new transaction for subsequent retries, see #resetForRetryAsync().

Initializes a new read-write transaction that is a retry of a previously aborted transaction. This method must be called before performing any operations, and it can only be invoked once per transaction lifecycle.

This method should only be used when multiplexed sessions are enabled to create a retry for a previously aborted transaction. This method can be used instead of #resetForRetryAsync() to create a retry. Using this method or #resetForRetryAsync() will have the same effect. You must pass in the AbortedException from the previous attempt to preserve the transaction's priority.

For regular sessions, this behaves the same as #beginAsync().

Closes the manager. If there is an active transaction, it will be rolled back. Underlying session will be released back to the session pool.

Closes the transaction manager. If there is an active transaction, it will be rolled back. The underlying session will be released back to the session pool. The returned ApiFuture is done when the transaction (if any) has been rolled back.

Returns the CommitResponse of this transaction.

Returns the state of the transaction.

Creates a new transaction for retry. This should only be called if the previous transaction failed with ABORTED. In all other cases, this will throw an IllegalStateException. Users should backoff before calling this method. Backoff delay is specified by SpannerException#getRetryDelayInMillis() on the SpannerException throw by the previous commit call.

Rolls back the currently active transaction. In most cases there should be no need to call this explicitly since #close() would automatically roll back any active transaction.