- 3.51.0 (latest)
- 3.50.1
- 3.46.0
- 3.45.0
- 3.44.0
- 3.43.0
- 3.42.0
- 3.41.0
- 3.40.1
- 3.39.0
- 3.38.0
- 3.37.0
- 3.36.0
- 3.35.1
- 3.34.0
- 3.33.0
- 3.32.0
- 3.31.0
- 3.30.0
- 3.29.0
- 3.28.0
- 3.27.1
- 3.26.0
- 3.25.0
- 3.24.0
- 3.23.0
- 3.22.2
- 3.21.0
- 3.20.0
- 3.19.0
- 3.18.0
- 3.17.0
- 3.16.0
- 3.15.1
- 3.14.1
- 3.13.0
- 3.12.1
- 3.11.1
- 3.10.0
- 3.9.0
- 3.8.0
- 3.7.0
- 3.6.0
- 3.5.0
- 3.4.0
- 3.3.0
- 3.2.0
- 3.1.0
- 3.0.0
- 2.1.1
- 2.0.0
- 1.19.3
- 1.18.0
- 1.17.1
- 1.16.0
- 1.15.1
- 1.14.0
- 1.13.0
- 1.12.0
- 1.11.0
- 1.10.0
LockHint(value)
A lock hint mechanism for reads done within a transaction.
LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
LOCK_HINT_SHARED (1):
Acquire shared locks.
By default when you perform a read as part of a read-write
transaction, Spanner acquires shared read locks, which
allows other reads to still access the data until your
transaction is ready to commit. When your transaction is
committing and writes are being applied, the transaction
attempts to upgrade to an exclusive lock for any data you
are writing. For more information about locks, see `Lock
modes <https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes>`__.
LOCK_HINT_EXCLUSIVE (2):
Acquire exclusive locks.
Requesting exclusive locks is beneficial if you observe high
write contention, which means you notice that multiple
transactions are concurrently trying to read and write to
the same data, resulting in a large number of aborts. This
problem occurs when two transactions initially acquire
shared locks and then both try to upgrade to exclusive locks
at the same time. In this situation both transactions are
waiting for the other to give up their lock, resulting in a
deadlocked situation. Spanner is able to detect this
occurring and force one of the transactions to abort.
However, this is a slow and expensive operation and results
in lower performance. In this case it makes sense to acquire
exclusive locks at the start of the transaction because then
when multiple transactions try to act on the same data, they
automatically get serialized. Each transaction waits its
turn to acquire the lock and avoids getting into deadlock
situations.
Because the exclusive lock hint is just a hint, it should
not be considered equivalent to a mutex. In other words, you
should not use Spanner exclusive locks as a mutual exclusion
mechanism for the execution of code outside of Spanner.
**Note:** Request exclusive locks judiciously because they
block others from reading that data for the entire
transaction, rather than just when the writes are being
performed. Unless you observe high write contention, you
should use the default of shared read locks so you don't
prematurely block other clients from reading the data that
you're writing to.
Enum |
|
---|---|
Name | Description |
LOCK_HINT_UNSPECIFIED |
Default value. |