Locks for reads within the transaction are not acquired on read.
Instead the locks are acquired on a commit to validate that
read/queried data has not changed since the transaction started.
Semantics described only applies to
[SERIALIZABLE][google.spanner.v1.TransactionOptions.IsolationLevel.SERIALIZABLE]
isolation.
Pessimistic
Pessimistic lock mode.
Read locks are acquired immediately on read.
Semantics described only applies to
[SERIALIZABLE][google.spanner.v1.TransactionOptions.IsolationLevel.SERIALIZABLE]
isolation.
Unspecified
Default value.
If isolation level is
[REPEATABLE_READ][google.spanner.v1.TransactionOptions.IsolationLevel.REPEATABLE_READ],
then it is an error to specify read_lock_mode. Locking semantics
default to OPTIMISTIC. No validation checks are done for reads,
except to validate that the data that was served at the snapshot time
is unchanged at commit time in the following cases:
reads done as part of queries that use SELECT FOR UPDATE
reads done as part of statements with a LOCK_SCANNED_RANGES
hint
reads done as part of DML statements
At all other isolation levels, if read_lock_mode is the default
value, then pessimistic read locks are used.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-10-01 UTC."],[],[]]