--- title: "POST /v1/{+session}:commit" method: POST path: "/v1/{+session}:commit" tags: ["projects"] --- # POST /v1/{+session}:commit `POST /v1/{+session}:commit` Commits a transaction. The request includes the mutations to be applied to rows in the database. `Commit` might return an `ABORTED` error. This can occur at any time; commonly, the cause is conflicts with concurrent transactions. However, it can also happen for a variety of other reasons. If `Commit` returns `ABORTED`, the caller should retry the transaction from the beginning, reusing the same session. On very rare occasions, `Commit` might return `UNKNOWN`. This can happen, for example, if the client job experiences a 1+ hour networking failure. At that point, Cloud Spanner has lost track of the transaction outcome and we recommend that you perform another read from the database to see the state of things as they are now. ## Path parameters - `session` string, required ## Request body - CommitRequest — The request for Commit. - `transactionId` string, byte — Commit a previously-started transaction. - `singleUseTransaction` TransactionOptions — Options to use for transactions. - `readWrite` ReadWrite — Message type to initiate a read-write transaction. Currently this transaction type has no options. - `readLockMode` 'READ_LOCK_MODE_UNSPECIFIED' | 'PESSIMISTIC' | 'OPTIMISTIC' — The read lock mode for the transaction. - `multiplexedSessionPreviousTransactionId` string, byte — Optional. Clients should pass the transaction ID of the previous transaction attempt that was aborted if this transaction is being executed on a multiplexed session. - `partitionedDml` PartitionedDml — Message type to initiate a Partitioned DML transaction. - `readOnly` ReadOnly — Message type to initiate a read-only transaction. - `strong` boolean — Read at a timestamp where all previously committed transactions are visible. - `minReadTimestamp` string, google-datetime — Executes all reads at a timestamp >= `min_read_timestamp`. This is useful for requesting fresher data than some previous read, or data that is fresh enough to observe the effects of some previously committed transaction whose timestamp is known. Note that this option can only be used in single-use transactions. A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds. Example: `"2014-10-02T15:01:23.045123456Z"`. - `maxStaleness` string, google-duration — Read data at a timestamp >= `NOW - max_staleness` seconds. Guarantees that all writes that have committed more than the specified number of seconds ago are visible. Because Cloud Spanner chooses the exact timestamp, this mode works even if the client's local clock is substantially skewed from Cloud Spanner commit timestamps. Useful for reading the freshest data available at a nearby replica, while bounding the possible staleness if the local replica has fallen behind. Note that this option can only be used in single-use transactions. - `readTimestamp` string, google-datetime — Executes all reads at the given timestamp. Unlike other modes, reads at a specific timestamp are repeatable; the same read at the same timestamp always returns the same data. If the timestamp is in the future, the read is blocked until the specified timestamp, modulo the read's deadline. Useful for large scale consistent reads such as mapreduces, or for coordinating many reads against a consistent snapshot of the data. A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds. Example: `"2014-10-02T15:01:23.045123456Z"`. - `exactStaleness` string, google-duration — Executes all reads at a timestamp that is `exact_staleness` old. The timestamp is chosen soon after the read is started. Guarantees that all writes that have committed more than the specified number of seconds ago are visible. Because Cloud Spanner chooses the exact timestamp, this mode works even if the client's local clock is substantially skewed from Cloud Spanner commit timestamps. Useful for reading at nearby replicas without the distributed timestamp negotiation overhead of `max_staleness`. - `returnReadTimestamp` boolean — If true, the Cloud Spanner-selected read timestamp is included in the Transaction message that describes the transaction. - `excludeTxnFromChangeStreams` boolean — When `exclude_txn_from_change_streams` is set to `true`, it prevents read or write transactions from being tracked in change streams. * If the DDL option `allow_txn_exclusion` is set to `true`, then the updates made within this transaction aren't recorded in the change stream. * If you don't set the DDL option `allow_txn_exclusion` or if it's set to `false`, then the updates made within this transaction are recorded in the change stream. When `exclude_txn_from_change_streams` is set to `false` or not set, modifications from this transaction are recorded in all change streams that are tracking columns modified by these transactions. The `exclude_txn_from_change_streams` option can only be specified for read-write or partitioned DML transactions, otherwise the API returns an `INVALID_ARGUMENT` error. - `isolationLevel` 'ISOLATION_LEVEL_UNSPECIFIED' | 'SERIALIZABLE' | 'REPEATABLE_READ' — Isolation level for the transaction. - `mutations` Mutation[] — The mutations to be executed when this transaction commits. All mutations are applied atomically, in the order they appear in this list. - `insert` Write — Arguments to insert, update, insert_or_update, and replace operations. - `table` string — Required. The table whose rows will be written. - `columns` string[] — The names of the columns in table to be written. The list of columns must contain enough columns to allow Cloud Spanner to derive values for all primary key columns in the row(s) to be modified. - `values` array[] — The values to be written. `values` can contain more than one list of values. If it does, then multiple rows are written, one for each entry in `values`. Each list in `values` must have exactly as many entries as there are entries in columns above. Sending multiple lists is equivalent to sending multiple `Mutation`s, each containing one `values` entry and repeating table and columns. Individual values in each list are encoded as described here. - unknown[] - unknown - `update` Write — Arguments to insert, update, insert_or_update, and replace operations. - `table` string — Required. The table whose rows will be written. - `columns` string[] — The names of the columns in table to be written. The list of columns must contain enough columns to allow Cloud Spanner to derive values for all primary key columns in the row(s) to be modified. - `values` array[] — The values to be written. `values` can contain more than one list of values. If it does, then multiple rows are written, one for each entry in `values`. Each list in `values` must have exactly as many entries as there are entries in columns above. Sending multiple lists is equivalent to sending multiple `Mutation`s, each containing one `values` entry and repeating table and columns. Individual values in each list are encoded as described here. - unknown[] - unknown - `insertOrUpdate` Write — Arguments to insert, update, insert_or_update, and replace operations. - `table` string — Required. The table whose rows will be written. - `columns` string[] — The names of the columns in table to be written. The list of columns must contain enough columns to allow Cloud Spanner to derive values for all primary key columns in the row(s) to be modified. - `values` array[] — The values to be written. `values` can contain more than one list of values. If it does, then multiple rows are written, one for each entry in `values`. Each list in `values` must have exactly as many entries as there are entries in columns above. Sending multiple lists is equivalent to sending multiple `Mutation`s, each containing one `values` entry and repeating table and columns. Individual values in each list are encoded as described here. - unknown[] - unknown - `replace` Write — Arguments to insert, update, insert_or_update, and replace operations. - `table` string — Required. The table whose rows will be written. - `columns` string[] — The names of the columns in table to be written. The list of columns must contain enough columns to allow Cloud Spanner to derive values for all primary key columns in the row(s) to be modified. - `values` array[] — The values to be written. `values` can contain more than one list of values. If it does, then multiple rows are written, one for each entry in `values`. Each list in `values` must have exactly as many entries as there are entries in columns above. Sending multiple lists is equivalent to sending multiple `Mutation`s, each containing one `values` entry and repeating table and columns. Individual values in each list are encoded as described here. - unknown[] - unknown - `delete` Delete — Arguments to delete operations. - `table` string — Required. The table whose rows will be deleted. - `keySet` KeySet — `KeySet` defines a collection of Cloud Spanner keys and/or key ranges. All the keys are expected to be in the same table or index. The keys need not be sorted in any particular way. If the same key is specified multiple times in the set (for example if two ranges, two keys, or a key and a range overlap), Cloud Spanner behaves as if the key were only specified once. - `keys` array[] — A list of specific keys. Entries in `keys` should have exactly as many elements as there are columns in the primary or index key with which this `KeySet` is used. Individual key values are encoded as described here. - unknown[] - unknown - `ranges` KeyRange[] — A list of key ranges. See KeyRange for more information about key range specifications. - `startClosed` unknown[] — If the start is closed, then the range includes all rows whose first `len(start_closed)` key columns exactly match `start_closed`. - unknown - `startOpen` unknown[] — If the start is open, then the range excludes rows whose first `len(start_open)` key columns exactly match `start_open`. - unknown - `endClosed` unknown[] — If the end is closed, then the range includes all rows whose first `len(end_closed)` key columns exactly match `end_closed`. - unknown - `endOpen` unknown[] — If the end is open, then the range excludes rows whose first `len(end_open)` key columns exactly match `end_open`. - unknown - `all` boolean — For convenience `all` can be set to `true` to indicate that this `KeySet` matches all keys in the table or index. Note that any keys specified in `keys` or `ranges` are only yielded once. - `send` Send — Arguments to send operations. - `queue` string — Required. The queue to which the message will be sent. - `key` unknown[] — Required. The primary key of the message to be sent. - unknown - `deliverTime` string, google-datetime — The time at which Spanner will begin attempting to deliver the message. If `deliver_time` is not set, Spanner will deliver the message immediately. If `deliver_time` is in the past, Spanner will replace it with a value closer to the current time. - `payload` unknown - `ack` Ack — Arguments to ack operations. - `queue` string — Required. The queue where the message to be acked is stored. - `key` unknown[] — Required. The primary key of the message to be acked. - unknown - `ignoreNotFound` boolean — By default, an attempt to ack a message that does not exist will fail with a `NOT_FOUND` error. With `ignore_not_found` set to true, the ack will succeed even if the message does not exist. This is useful for unconditionally acking a message, even if it is missing or has already been acked. - `returnCommitStats` boolean — If `true`, then statistics related to the transaction is included in the CommitResponse. Default value is `false`. - `maxCommitDelay` string, google-duration — Optional. The amount of latency this request is configured to incur in order to improve throughput. If this field isn't set, Spanner assumes requests are relatively latency sensitive and automatically determines an appropriate delay time. You can specify a commit delay value between 0 and 500 ms. - `requestOptions` RequestOptions — Common request options for various APIs. - `priority` 'PRIORITY_UNSPECIFIED' | 'PRIORITY_LOW' | 'PRIORITY_MEDIUM' | 'PRIORITY_HIGH' — Priority for the request. - `requestTag` string — A per-request tag which can be applied to queries or reads, used for statistics collection. Both `request_tag` and `transaction_tag` can be specified for a read or query that belongs to a transaction. This field is ignored for requests where it's not applicable (for example, `CommitRequest`). Legal characters for `request_tag` values are all printable characters (ASCII 32 - 126) and the length of a request_tag is limited to 50 characters. Values that exceed this limit are truncated. Any leading underscore (_) characters are removed from the string. - `transactionTag` string — A tag used for statistics collection about this transaction. Both `request_tag` and `transaction_tag` can be specified for a read or query that belongs to a transaction. To enable tagging on a transaction, `transaction_tag` must be set to the same value for all requests belonging to the same transaction, including BeginTransaction. If this request doesn't belong to any transaction, `transaction_tag` is ignored. Legal characters for `transaction_tag` values are all printable characters (ASCII 32 - 126) and the length of a `transaction_tag` is limited to 50 characters. Values that exceed this limit are truncated. Any leading underscore (_) characters are removed from the string. - `clientContext` ClientContext — Container for various pieces of client-owned context attached to a request. - `secureContext` object — Optional. Map of parameter name to value for this request. These values will be returned by any SECURE_CONTEXT() calls invoked by this request (e.g., by queries against Parameterized Secure Views). - `precommitToken` MultiplexedSessionPrecommitToken — When a read-write transaction is executed on a multiplexed session, this precommit token is sent back to the client as a part of the Transaction message in the BeginTransaction response and also as a part of the ResultSet and PartialResultSet responses. - `precommitToken` string, byte — Opaque precommit token. - `seqNum` integer — An incrementing seq number is generated on every precommit token that is returned. Clients should remember the precommit token with the highest sequence number from the current transaction attempt. ## Response `200` Successful response --- [API](https://skmtc.net/google/apis/spanner.md) · [All operations](https://skmtc.net/google/apis/spanner/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/google/spanner/versions/4b66067d2622/schema)