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 isolation.
Pessimistic
Pessimistic lock mode.
Read locks are acquired immediately on read.
Semantics described only applies to SERIALIZABLE isolation.
Unspecified
Default value.
If isolation level is 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 for:
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
to validate that the data that was served at the snapshot time is
unchanged at commit time.
At all other isolation levels, if read_lock_mode is the default
value, then pessimistic read lock is used.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[],[],null,[]]